make menuconfig on media_build

[Thomas Kaiser]

Dear List

When I run "make menuconfig" on media_build the following errors occur:

thomas@Intel64:~/Projects/dvb/media_build$ make menuconfig
make -C /home/thomas/Projects/dvb/media_build/v4l menuconfig
make[1]: Entering directory '/home/thomas/Projects/dvb/media_build/v4l'
/lib/modules/4.10.0-33-generic/build/scripts/kconfig/mconf ./Kconfig
./Kconfig:5033: syntax error
./Kconfig:5032: unknown option "Choose"
./Kconfig:5035: syntax error
./Kconfig:5034:warning: ignoring unsupported character ','
./Kconfig:5034: unknown option "In"
./Kconfig:5035: unknown option "that"
./Kconfig:5036: unknown option "this"
./Kconfig:5036:warning: ignoring unsupported character '<'
./Kconfig:5037:warning: ignoring unsupported character ':'
./Kconfig:5037: unknown option "file"
Makefile:379: recipe for target 'menuconfig' failed
make[1]: *** [menuconfig] Error 1
make[1]: Leaving directory '/home/thomas/Projects/dvb/media_build/v4l'
Makefile:26: recipe for target 'menuconfig' failed
make: *** [menuconfig] Error 2
thomas@Intel64:~/Projects/dvb/media_build$

The 2 spaces in the 2 lines after the "--help--" entry of "config RADIO_WL128X" 
are the problem (v4l/Kconfig).

Anyway I don't know where these 2 spaces come from. In the media_tree, I don't 
see these two spaces.

Can somebody look what is going wrong here, thanks.

Thomas

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Thomas Kaiser]

On 20.06.2017 00:14, Jasmin J. wrote:

Hello !

On 06/19/2017 10:18 PM, Daniel Scheller wrote:

Am Sun, 28 May 2017 23:45:37 +0200
schrieb Daniel Scheller :


Am Sun, 7 May 2017 17:42:12 +0200
schrieb Daniel Scheller :


Am Wed, 12 Apr 2017 21:23:27 +0200
schrieb Daniel Scheller :
   

Am Wed, 29 Mar 2017 18:43:00 +0200
schrieb Daniel Scheller :
 

From: Daniel Scheller 

Third iteration of the DD CineCTv6/FlexCT support patches with
mostly all things cleaned up that popped up so far. Obsoletes V1
and V2 series.

These patches enhance the functionality of dvb-frontends/stv0367
to work with Digital Devices hardware driven by the ST STV0367
demodulator chip and adds probe & attach bits to ddbridge to
make use of them, effectively enabling full support for
CineCTv6 PCIe bridges and (older) DuoFlex CT addon
modules.


Since V1 was sent over five weeks ago: Ping? Anyone? I'd really
like to get this upstreamed.


Don't want to sound impatient, but V1 nears nine weeks, so: Second
Ping.


Friendly third time Ping on this - Really, I'd like to have this
merged so those quite aging (but still fine) DD CineCTv6 boards
finally are supported without having to install out-of-tree drivers
which even break the V4L-DVB subsystem...


Well. From how things look, these and the cxd2841er+C2T2 ddbridge
support patches won't make it in time for the 4.13 merge window.
Also, unfortunately, the original owners and/or maintainers of the
affected drivers (besides cxd2841er), namely stv0367 and ddbridge,
either are MIA or not interested in reviewing or acking this.

I have plenty of more work (patches) done, all building upon this CT
and C2T2 hardware support, which - together with the work Jasmin has
done regarding the en50221 and cxd2099 support - would finally bring
the in-tree ddbridge driver on par with the package Digital Devices'
provides, having addressed most of the critics the previous attempts to
bump the driver received (incremental changes which are more or less
easy to review, from what can be done by tearing tarballs without
proper changelogs apart).

The original series of this will be four(!) months old soon :/

Is there anything wrong with this? How to proceed with this?

(Cc Hans since you also seem to be reviewing patches)

That said, fourth ping.


May I add another aspect.
Daniel put a lot of effort into this and also other people in testing his
drivers. Daniel was highly motivated to bring this driver into the Kernel.

That sayd, waiting 4 months is pretty frustrating and might reduce the
motivation to continue.

There are 7 more patch series waiting to review and when each of then requires
4 or more months to get into the Kernel, the project is dead before it really
started!

The community using the DD cards is growing and it is often frustrating using
the drivers provided by DD, when you plan to use other cards too, because
the DD drivers are simply not compatible.
Daniel made them working within the current media tree and a lot of people
(including me) would be very happy to see the DD cards supported out of the
box by the Kernel. Hopefully before the Kernel 5.x development hast started.

I hope there will be soon a review of this series, so that we can move forward
with our work!

BR,
Jasmin



Hello Reviewers

Me too, I would be very happy to see this driver included in the kernel.

Regards,

Thomas

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

[Thomas Kaiser]

On 28.05.2017 21:33, Karl Wallin wrote:

Thanks for such a quick reply :)

Of course *facepalm* should have thought of that "./build" downloads
everything again and of course replaces my modified "cec-core.c".
I ran "make" and ran into new problems:


Ok so using logic I should do the same changes in
"/home/ubuntu/media_build/v4l/media-devnode.c":
In ""/home/ubuntu/media_build/v4l/media-devnode.c" changed row 257 from:
"ret = cdev_device_add(>cdev, >dev);" to:
"ret = device_add(>dev);"
and row 293 from:
"cdev_device_del(>cdev, >dev);" to:
"device_del(>dev);"
and then run "make"

However it fails again :(




   CC [M]  /home/ubuntu/media_build/v4l/serial_ir.o
/home/ubuntu/media_build/v4l/serial_ir.c:837:21: error: expected ')'
before 'int'
  module_param_hw(io, int, ioport, 0444);
  ^~~
/home/ubuntu/media_build/v4l/serial_ir.c:841:25: error: expected ')'
before 'ulong'
  module_param_hw(iommap, ulong, other, 0444);
  ^
/home/ubuntu/media_build/v4l/serial_ir.c:849:26: error: expected ')'
before 'int'
  module_param_hw(ioshift, int, other, 0444);
   ^~~
/home/ubuntu/media_build/v4l/serial_ir.c:852:22: error: expected ')'
before 'int'
  module_param_hw(irq, int, irq, 0444);
   ^~~
/home/ubuntu/media_build/v4l/serial_ir.c:855:28: error: expected ')'
before 'bool'
  module_param_hw(share_irq, bool, other, 0444);
 ^~~~
scripts/Makefile.build:301: recipe for target
'/home/ubuntu/media_build/v4l/serial_ir.o' failed
make[3]: *** [/home/ubuntu/media_build/v4l/serial_ir.o] Error 1
Makefile:1524: recipe for target '_module_/home/ubuntu/media_build/v4l' failed
make[2]: *** [_module_/home/ubuntu/media_build/v4l] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-4.10.0-21-generic'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory '/home/ubuntu/media_build/v4l'
Makefile:26: recipe for target 'all' failed
make: *** [all] Error 2

So I'm guessing that "/home/ubuntu/media_build/v4l/serial_ir.c" needs
to be modified since it expects a ")" before the integer (numerical)
value?

/Karl


Hi Karl

I compiled only the ddbridge driver. So I did not have to compile these files 
you have problems with. Therefor I don't know what is going on here, sorry.

Thomas

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

[Thomas Kaiser]

On 28.05.2017 21:06, Karl Wallin wrote:

Hi Thomas,

Thanks for the help (and to Vincent as well) :)

In "/home/ubuntu/media_build/v4l/cec-core.c" changed row 142 from:
"ret = cdev_device_add(>cdev, >dev);" to:
"ret = device_add(>dev);"
and row 186 from:
"cdev_device_del(>cdev, >dev);" to:
"device_del(>dev);"

Even if I do that when I try to build it again (using ./build) it
seems to reload / revert the cec-core.c to the original file since I
still get these errors even though I saved the changes in Notepadqq:
"/home/ubuntu/media_build/v4l/cec-core.c:142:8: error: implicit
declaration of function 'cdev_device_add'
[-Werror=implicit-function-declaration]
   ret = cdev_device_add(>cdev, >dev);"
and
"/home/ubuntu/media_build/v4l/cec-core.c:186:2: error: implicit
declaration of function 'cdev_device_del'
[-Werror=implicit-function-declaration]
   cdev_device_del(>cdev, >dev);"

I am probably missing something here since it worked for you, would be
grateful for your help :)

/Karl
Med vänlig hälsning / Best Regards - Karl Wallin



Hi Karl

The build downloads the latest source and overwrites your change (I think?)

I used "make" to compile.

After your have run the build script. Do the changes as you have described above. Run 
"make" to compile and "sudo make install" to install. This should do the trick.

Thomas

Re: ddbridge -- kernel 3.15.6

[Thomas Kaiser]

On 08/01/2014 07:08 AM, Georgi Chorbadzhiyski wrote:

On 8/1/14 7:54 AM, Bjoern wrote:

On Do, 2014-07-31 at 09:38 +0200, Ralph Metzler wrote:



It is not like drivers are not available and supported, just
not in the mainline kernel tree.


Right... and I hope that can be changed. I really really like the DD
hardware I have, but always having to rebuild everything with a new
kernel is just not my idea of how hardware should run in 2014 on Linux
anymore.


I have more than 30 ddbridge dvb-s devices and more than 30 dvb-c/t devices.

The fact that the drivers are not in the main tree is the biggest problem
with these devices. The hardware is great (never had a problem with it)
but having to install experimental media build is just stupid.

When I bought the devices I knew that the driver is not in the main tree
but I really hoped that this would change. Now 3 years later it is still
not the case. That's bullshit.

Come on Digital Devices, you have the drivers, please, pretty please, submit
them upstream, go through the merge process and make us - our clients a
happy bunch.

Like Bjoern said, it's 2014, you have the drivers, keeping them out
of main kernel and having your customers go through hoops to get them
working is not acceptable.



I would love to see the driver in the kernel mainline tree for the above 
mentioned reasons!

Thomas


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ddbridge -- kernel 3.15.6

[Thomas Kaiser]

On 07/30/2014 11:03 PM, Rudy Zijlstra wrote:

On 19-07-14 19:49, Thomas Kaiser wrote:


Hello Rudy

I use a similar card from Digital Devices with Ubuntu 14.04 and kernel
3.13.0-32-generic. Support for this card was not build into the kernel
and I had to compile it myself. I had to use media_build_experimental
from Mr. Endriss.

http://linuxtv.org/hg/~endriss/media_build_experimental

Your card should be supported with this version.

Regards, Thomas



Hi Thomas,

thank you for the information.

Is there a preferred kernel for the experimental?

Cheers


Rudy


Hello Rudy

I don't know!
I use it with Ubuntu 14.04 and kernel 3.13.0, right know. But I used it with 
older Ubuntu Versions (13.10, 13.04) and there kernels, too. I think it should 
compile with the newest kernel also.

Thomas




--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ddbridge -- kernel 3.15.6

[Thomas Kaiser]

On 07/18/2014 03:28 PM, Rudy Zijlstra wrote:

Dears,

I have a ddbridge device:

03:00.0 Multimedia controller: Device dd01:0003
  Subsystem: Device dd01:0021
  Flags: fast devsel, IRQ 17
  Memory at f090 (64-bit, non-prefetchable) [size=64K]
  Capabilities: [50] Power Management version 3
  Capabilities: [90] Express Endpoint, MSI 00
  Capabilities: [100] Vendor Specific Information: ID= Rev=0
Len=00c ?
  Kernel driver in use: DDBridge

The kernel recognises as seen in dmesg:

[1.811626] Digital Devices PCIE bridge driver, Copyright (C) 2010-11
Digital Devices GmbH
[1.813996] pci :01:19.0: enabling device ( - 0002)
[1.816033] DDBridge driver detected: Digital Devices PCIe bridge
[1.816273] HW 0001000d FW 00010004

But /dev/dvb remains empty, only /dev/ddbridge exists.

Any pointers are much appreciated

Cheers


Rudy


Hello Rudy

I use a similar card from Digital Devices with Ubuntu 14.04 and kernel 
3.13.0-32-generic. Support for this card was not build into the kernel and I 
had to compile it myself. I had to use media_build_experimental from Mr. 
Endriss.

http://linuxtv.org/hg/~endriss/media_build_experimental

Your card should be supported with this version.

Regards, Thomas




--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Retrieving the Source Code Building/Compiling the Modules

[Thomas Kaiser]

Hi

I followed the instructions on:
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

Developer's Approach

When I edit drivers/media/dvb/ddbridge/ddbridge-core.c and do make -C 
../v4l, my changes are not compiled.


What I am doing wrong?

Thomas


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [DVB Digital Devices Cine CT V6] status support

[Thomas Kaiser]

On 01/09/2012 09:05 AM, Martin Herrman wrote:

2012/1/8 Sébastien RAILLARD (COEXSI)s...@coexsi.fr:



http://shop.digital-
devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/62357162/Categori
es/HDTV_Karten_fuer_Mediacenter/Cine_PCIe_Serie/DVBC_T

But.. is this card supported by the Linux kernel?



The short answer is yes, and as far as I know, it's working fine with DVB-T
(I've never tested the DVB-C).
For support, you need to compile the drivers from Oliver Endriss as they are
not merged in mainstream kernel.

Check here (kernel  2.6.31):
http://linuxtv.org/hg/~endriss/media_build_experimental/
Or here (kernel  2.6.36) :
http://linuxtv.org/hg/~endriss/ngene-octopus-test/


Hi Sébastien,

thanks for your quick and positive reply.

Anyone here that tested it with DVB-C?

Are there any plans to merge this in the mainstream kernel?

Regards,

Martin


Hello Martin

I use the DD Cine CT V6 with DVB-C. It works without problems.
I got the driver before Oliver integrated it in his tree. Therefor I did 
not compile Olivers tree, yet.


At the moment I run the card on Ubuntu 11.10 with kernel 3.0.0-14.

Hope this helps.

Thomas


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DD Cine CT DVB-C/T

[Thomas Kaiser]

On 08/25/2011 06:47 PM, Thomas Kaiser wrote:

Hi

Which modules do I have to build and install to use this card (DD Cine 
CT DVB-C/T Rev. V6).


I checkd out:
hg clone http://linuxtv.org/hg/~endriss/media_build_experimental

I would like to build only the needed modules. What do I have to 
select in make menuconfig?


Regards, Thomas


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Looks like I took the wrong source...

static const struct pci_device_id ddb_id_tbl[] __devinitdata = {
DDB_ID(DDVID, 0x0002, DDVID, 0x0001, ddb_octopus),
DDB_ID(DDVID, 0x0003, DDVID, 0x0001, ddb_octopus),
DDB_ID(DDVID, 0x0003, DDVID, 0x0002, ddb_octopus_le),
DDB_ID(DDVID, 0x0003, DDVID, 0x0010, ddb_octopus),
DDB_ID(DDVID, 0x0003, DDVID, 0x0020, ddb_v6),
/* in case sub-ids got deleted in flash */
DDB_ID(DDVID, 0x0003, PCI_ANY_ID, PCI_ANY_ID, ddb_none),
{0}
};

My card has the _subdev 0x0030!

Where can I find the right source code for this card?

I am ready to help developing and testing.

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

DD Cine CT DVB-C/T

[Thomas Kaiser]

Hi

Which modules do I have to build and install to use this card (DD Cine 
CT DVB-C/T Rev. V6).


I checkd out:
hg clone http://linuxtv.org/hg/~endriss/media_build_experimental

I would like to build only the needed modules. What do I have to select 
in make menuconfig?


Regards, Thomas


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCHES FOR 2.6.37] Remove V4L1 support from the pwc driver

[Thomas Kaiser]

On 09/13/2010 03:30 PM, Andy Walls wrote:

On Mon, 2010-09-13 at 08:27 -0300, Mauro Carvalho Chehab wrote:

Em 12-09-2010 18:28, Andy Walls escreveu:

On Sun, 2010-09-12 at 17:12 -0400, Andy Walls wrote:

On Sun, 2010-09-12 at 22:26 +0200, Hans Verkuil wrote:


And other news on the V4L1 front:



I'm waiting for test results on the cpia2 driver. If it works, then the V4L1
support can be removed from that driver as well.


FYI, that will break this 2005 vintage piece of V4L1 software people may
still be using for the QX5 microscope:


Sorry, that is of course, if there is no V4L1 compat layer still in
place.

BTW, qx5view uses a private ioctl() to change the lights on a QX5 and
not the V4L2 control.


The better would be to port qx5view to use libv4l and implement the new
illuminator ctrl on the driver and on the userspase app. Do you have
hardware for testing this?


No.  I did check Amazon.com and eBay and saw a QX5 for about US$75 after
shipping costs:

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=380262406989rvr_id=139147359954crlp=1_263602_263622UA=L*F%3FGUID=0b3b537412b0a0e203e63006ff9becb0itemid=380262406989ff4=263602_263622

I'm not sure if I want to buy one at that price, since I already have a
QX3.

Regards,
Andy

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Hello Andy, Mauro

I own a USB Microscope which looks quite the same as the one in your 
link, but I don't know if it is similar to the QX3 or QX5.

It is called Traveler USB-Mikroskop and model number is SU 1071.
One of this two:
http://www.traveler-service.de/cms/index.php?id=traveler-optische-geraete-de

USB ID: 1871:01b0 Aveo Technology Corp.

It is not working in Ubuntu 10.04, kernel AMD64 2.6.32-24-generic.

If it is a QX5, I can help testing.

Regards,
Thomas


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH libv4l tree, RFC] libv4l: skip false Pixart markers with buffer copy

[Thomas Kaiser]

On 02/05/2010 02:42 PM, Hans de Goede wrote:
Good job! I never noticed the ff ff ff xx markers where spaced a certain 
numbers


You can find this info here 
http://www.kaiser-linux.li/index.php?title=PAC7311

go down the page to 2006-11-12

Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libv4l: possible problem found in PAC7302 JPEG decoding

[Thomas Kaiser]

On 02/01/2010 10:23 PM, Németh Márton wrote:

Hello Hans,

while I was dealing with Labtec Webcam 2200 and with gspca_pac7302 driver I 
recognised the
following behaviour. The stream received from the webcam is splitted by the 
gspca_pac7302
subdriver when the byte sequence 0xff, 0xff, 0x00, 0xff, 0x96 is found 
(pac_find_sof()).
Before transmitting the data to the userspace a JPEG header is added 
(pac_start_frame())
and the footer after the bytes 0xff, 0xd9 are removed.

The data buffer which arrives to userspace looks like as follows (maybe not 
every detail is exact):

 1. JPEG header

 2. Some bytes of image data (near to 1024 bytes)

 3. The byte sequence 0xff, 0xff, 0xff, 0x01 followed by 1024 bytes of data.
This marker sequence and data repeats a couple of time. Exactly how much
depends on the image content.

 4. The byte sequence 0xff, 0xff, 0xff, 0x02 followed by 512 bytes of data.
This marker sequence and data also repeats a couple of time.

 5. The byte sequence 0xff, 0xff, 0xff, 0x00 followed by a variable amount of
image data bytes.

 6. The End of Image (EOI) marker 0xff, 0xd9.

Now what can be wrong with the libv4l? In libv4lconvert/tinyjpeg.c, line 315 
there is a
huge macro which tries to remove the 0xff, 0xff, 0xff, xx byte sequence from 
the received
image. This fails, however, if the image contains 0xff bytes just before the 
0xff, 0xff,
0xff, xx sequence because one byte from the image data (the first 0xff) is 
removed, then
the three 0xff bytes from the marker is also removed. The xx (which really 
belongs to the
marker) is left in the image data instead of the original 0xff byte.

Based on my experiments this problem sometimes causes corrupted image decoding 
or that the
JPEG image cannot be decoded at all.



Hello Németh

I remember the problem as I was working on the PAC7311.
http://www.kaiser-linux.li/index.php?title=PAC7311


This is the code I used in the JPEG decoder to remove the 0xff 0xff 0xff 
 0xnn markers.


See http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz
decoder/gspcadecoder.c pac7311_decode()

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libv4l: possible problem found in PAC7302 JPEG decoding

[Thomas Kaiser]

On 02/02/2010 07:59 PM, Németh Márton wrote:

Hi Thomas,
Thomas Kaiser wrote:

On 02/01/2010 10:23 PM, Németh Márton wrote:

Hello Hans,

while I was dealing with Labtec Webcam 2200 and with gspca_pac7302 driver I 
recognised the
following behaviour. The stream received from the webcam is splitted by the 
gspca_pac7302
subdriver when the byte sequence 0xff, 0xff, 0x00, 0xff, 0x96 is found 
(pac_find_sof()).
Before transmitting the data to the userspace a JPEG header is added 
(pac_start_frame())
and the footer after the bytes 0xff, 0xd9 are removed.

The data buffer which arrives to userspace looks like as follows (maybe not 
every detail is exact):

 1. JPEG header

 2. Some bytes of image data (near to 1024 bytes)

 3. The byte sequence 0xff, 0xff, 0xff, 0x01 followed by 1024 bytes of data.
This marker sequence and data repeats a couple of time. Exactly how much
depends on the image content.

 4. The byte sequence 0xff, 0xff, 0xff, 0x02 followed by 512 bytes of data.
This marker sequence and data also repeats a couple of time.

 5. The byte sequence 0xff, 0xff, 0xff, 0x00 followed by a variable amount of
image data bytes.

 6. The End of Image (EOI) marker 0xff, 0xd9.

Now what can be wrong with the libv4l? In libv4lconvert/tinyjpeg.c, line 315 
there is a
huge macro which tries to remove the 0xff, 0xff, 0xff, xx byte sequence from 
the received
image. This fails, however, if the image contains 0xff bytes just before the 
0xff, 0xff,
0xff, xx sequence because one byte from the image data (the first 0xff) is 
removed, then
the three 0xff bytes from the marker is also removed. The xx (which really 
belongs to the
marker) is left in the image data instead of the original 0xff byte.

Based on my experiments this problem sometimes causes corrupted image decoding 
or that the
JPEG image cannot be decoded at all.


Hello Németh

I remember the problem as I was working on the PAC7311.
http://www.kaiser-linux.li/index.php?title=PAC7311


This is the code I used in the JPEG decoder to remove the 0xff 0xff 0xff 
  0xnn markers.


See http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz
decoder/gspcadecoder.c pac7311_decode()


Do you remember whether this code was working properly always?


Hello Németh

I am not 100% sure but it looked OK for me.

Anyway, we have to throw away these markers before the JPEG decoding 
starts. I don't think this code will fail when you parse the Byte stream 
(frame header removed before!).

We don't know these markers, so we don't need them.

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: image quality of Labtec Webcam 2200

[Thomas Kaiser]

On 09/13/2009 04:42 PM, leandro Costantino wrote:

Actually it based on pac7302. Pac7311/02 also has support ( since gspca1 ).

I checked some old logs of the pac, and the driver init for 7302 seems ok.

The ff ff ff sequence, seems to been taken in account on conversion.
(libv4lconvert)

/* Special Pixart versions of the *_nbits functions, these remove the special
   ff ff ff xx sequences pixart cams insert from the bitstream */
#define pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted) \

This is really a tricky cam. I be back on windows to do further test.


Hey All

I thought Hans will come in, in this discussion...

Anyway, I introduced support for the PAC7311 in gspcaV1 in 2006 [1]

Pixart is using a proprietary JEPG Format to code the image. It took me 
(and help from Jörg Schummer) more than a year to find out the basics 
to decode a frame.


They have this 0xffxx markers in the stream, I don't know for what 
this is good, just skip it. And they have a MCU marker for each MCU. 
As we know so far, this MCU marker tells what Quantization table should 
be used for decoding the MCU.


Hans did implement my findings into lib4vl and improved it :-)

So, when you get this errors, this is due to a unknown format Pixart is 
using.


I guess we should know what marker you get and how the image should look 
like.


Don't forget, this is all re-engineered - guess work!

Thomas


[1] http://www.kaiser-linux.li/index.php?title=PAC7311
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Using MSI StarCam 370i Webcam with Kubuntu Linux

[Thomas Kaiser]

On 08/29/2009 06:57 PM, Dotan Cohen wrote:

2009/8/28 Thomas Kaiser v...@kaiser-linux.li:

On 08/28/2009 08:40 PM, Dotan Cohen wrote:

I have the MSI StarCam 370i Webcam and I have trying to use it with
Kubuntu Linux 9.04 Jaunty. According to this page, The StarCam 370i
is compliant with UVC, USB video class:

http://gadgets.softpedia.com/gadgets/Computer-Peripherals/The-MSI-StarCam-370i-3105.html

According to the Linux UVC driver and tools download page, Linux
2.6.26 and newer includes the Linux UVC driver natively which is nice
as I am on a higher version:
$ uname -r
2.6.28-15-generic

However, plugging in the webcam and testing with camorama, cheese, and
luvcview led me to no results:

jaun...@laptop:~$ luvcview -f yuv
luvcview 0.2.4

SDL information:
 Video driver: x11
 A window manager is available
Device information:
 Device path:  /dev/video0
Stream settings:
ERROR: Requested frame format YUYV is not available and no fallback
format was found.
 Init v4L2 failed !! exit fatal
jaun...@laptop:~$ luvcview -f uyvy
luvcview 0.2.4

SDL information:
 Video driver: x11
 A window manager is available
Device information:
 Device path:  /dev/video0
Stream settings:
ERROR: Requested frame format UYVY is not available and no fallback
format was found.
 Init v4L2 failed !! exit fatal
jaun...@laptop:~$ luvcview
luvcview 0.2.4

SDL information:
 Video driver: x11
 A window manager is available
Device information:
 Device path:  /dev/video0
Stream settings:
ERROR: Requested frame format MJPG is not available and no fallback
format was found.
 Init v4L2 failed !! exit fatal


Some more details:

jaun...@laptop:~$ ls /dev/vi*
/dev/video0
jaun...@laptop:~$ dmesg | tail
[ 2777.811972] sn9c102: V4L2 driver for SN9C1xx PC Camera Controllers
v1:1.47pre49
[ 2777.814989] usb 2-1: SN9C105 PC Camera Controller detected (vid:pid
0x0C45:0x60FC)
[ 2777.842123] usb 2-1: HV7131R image sensor detected
[ 2778.185108] usb 2-1: Initialization succeeded
[ 2778.185220] usb 2-1: V4L2 device registered as /dev/video0
[ 2778.185225] usb 2-1: Optional device control through 'sysfs'
interface disabled
[ 2778.185283] usbcore: registered new interface driver sn9c102
[ 2778.216691] usbcore: registered new interface driver snd-usb-audio
[ 2778.218738] usbcore: registered new interface driver sonixj
[ 2778.218745] sonixj: registered
jaun...@laptop:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 413c:8126 Dell Computer Corp. Wireless 355
Bluetooth
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 004: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 004 Device 003: ID 045e:00db Microsoft Corp. Natural Ergonomic
Keyboard 4000 V1.0
Bus 004 Device 002: ID 05e3:0604 Genesys Logic, Inc. USB 1.1 Hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0c45:60fc Microdia PC Camera with Mic (SN9C105)
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
jaun...@laptop:~$



Anything missing? What should I do? Thanks in advance!

Hello Dotan, me again ;-)

Looks like your cam is detected, but does not provide a good frame format.
You my have to use libv4l to convert to a know format.

See: http://hansdegoede.livejournal.com/7622.html



Thanks. I will go through that tomorrow, but in the meantime I got a
strange result. Despite the fact  that this is a 32 bit Kubuntu
install, I got these results from the tests at the beginning of the
page:

jaun...@laptop:~$ ls -d /usr/lib64
/usr/lib64
jaun...@laptop:~$ ls -d /usr/lib32
ls: cannot access /usr/lib32: No such file or directory
jaun...@laptop:~$


According to what is written, with those results I should use the
Fedora multilib instructions. Does that not sound unusual?



Yes, this looks somehow strange. I don't have a 32 bit system at the 
moment to verify.


You know you have 32 bit, then just use the none multilib instructions.

You can install the version which ships with Ubuntu:
sudo apt-get install libv4l-0

then do,

To use a v4l1 aware application this should do it:
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so your favorite webcam app

For a v4l2 aware application you should use:
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so your favorite webcam app
to convert to a known video format.

Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Using MSI StarCam 370i Webcam with Kubuntu Linux

[Thomas Kaiser]

On 08/28/2009 08:40 PM, Dotan Cohen wrote:

I have the MSI StarCam 370i Webcam and I have trying to use it with
Kubuntu Linux 9.04 Jaunty. According to this page, The StarCam 370i
is compliant with UVC, USB video class:
http://gadgets.softpedia.com/gadgets/Computer-Peripherals/The-MSI-StarCam-370i-3105.html

According to the Linux UVC driver and tools download page, Linux
2.6.26 and newer includes the Linux UVC driver natively which is nice
as I am on a higher version:
$ uname -r
2.6.28-15-generic

However, plugging in the webcam and testing with camorama, cheese, and
luvcview led me to no results:

jaun...@laptop:~$ luvcview -f yuv
luvcview 0.2.4

SDL information:
 Video driver: x11
 A window manager is available
Device information:
 Device path:  /dev/video0
Stream settings:
ERROR: Requested frame format YUYV is not available and no fallback
format was found.
 Init v4L2 failed !! exit fatal
jaun...@laptop:~$ luvcview -f uyvy
luvcview 0.2.4

SDL information:
 Video driver: x11
 A window manager is available
Device information:
 Device path:  /dev/video0
Stream settings:
ERROR: Requested frame format UYVY is not available and no fallback
format was found.
 Init v4L2 failed !! exit fatal
jaun...@laptop:~$ luvcview
luvcview 0.2.4

SDL information:
 Video driver: x11
 A window manager is available
Device information:
 Device path:  /dev/video0
Stream settings:
ERROR: Requested frame format MJPG is not available and no fallback
format was found.
 Init v4L2 failed !! exit fatal


Some more details:

jaun...@laptop:~$ ls /dev/vi*
/dev/video0
jaun...@laptop:~$ dmesg | tail
[ 2777.811972] sn9c102: V4L2 driver for SN9C1xx PC Camera Controllers
v1:1.47pre49
[ 2777.814989] usb 2-1: SN9C105 PC Camera Controller detected (vid:pid
0x0C45:0x60FC)
[ 2777.842123] usb 2-1: HV7131R image sensor detected
[ 2778.185108] usb 2-1: Initialization succeeded
[ 2778.185220] usb 2-1: V4L2 device registered as /dev/video0
[ 2778.185225] usb 2-1: Optional device control through 'sysfs'
interface disabled
[ 2778.185283] usbcore: registered new interface driver sn9c102
[ 2778.216691] usbcore: registered new interface driver snd-usb-audio
[ 2778.218738] usbcore: registered new interface driver sonixj
[ 2778.218745] sonixj: registered
jaun...@laptop:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 004: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 004 Device 003: ID 045e:00db Microsoft Corp. Natural Ergonomic
Keyboard 4000 V1.0
Bus 004 Device 002: ID 05e3:0604 Genesys Logic, Inc. USB 1.1 Hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0c45:60fc Microdia PC Camera with Mic (SN9C105)
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
jaun...@laptop:~$



Anything missing? What should I do? Thanks in advance!


Hello Dotan, me again ;-)

Looks like your cam is detected, but does not provide a good frame 
format. You my have to use libv4l to convert to a know format.


See: http://hansdegoede.livejournal.com/7622.html

and it is provided by Ubuntu:

tho...@amd64:~$ cat /etc/issue
Ubuntu 9.04 \n \l

tho...@amd64:~$ uname -a
Linux AMD64 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 19:25:34 UTC 
2009 x86_64 GNU/Linux


tho...@amd64:~$ apt-cache show libv4l-0
Package: libv4l-0
Priority: optional
Section: libs
Installed-Size: 256
Maintainer: Ubuntu Core Developers ubuntu-devel-disc...@lists.ubuntu.com
Original-Maintainer: Gregor Jasny gja...@web.de
Architecture: amd64
Source: libv4l
Version: 0.5.8-1
Depends: libc6 (= 2.4)
Filename: pool/main/libv/libv4l/libv4l-0_0.5.8-1_amd64.deb
Size: 64680
MD5sum: c7011003567b7ea3d4271f677ec28c7a
SHA1: 43a623f0b74b506cee8b7b15e1db996040358294
SHA256: 16cc3199df039259500657db98788ea39b7615a9080ffa4e7159a66f2b8a8b6e
Description: Collection of video4linux support libraries
 libv4l is a collection of libraries which adds a thin abstraction layer on
 top of video4linux2 devices. The purpose of this (thin) layer is to 
make it

 easy for application writers to support a wide variety of devices without
 having to write separate code for different devices in the same class. 
libv4l

 consists of 3 different libraries: libv4lconvert, libv4l1 and libv4l2.
 .
 libv4lconvert offers functions to convert from any (known) pixelformat
 to BGR24, RGB24, YUV420 and YVU420.
 .
 libv4l1 offers the (deprecated) v4l1 API on top of v4l2 devices, 
independent

 of the drivers for those devices supporting v4l1 compatibility (which many
 v4l2 drivers do not).
 .
 libv4l2 offers the v4l2 API on top of v4l2 devices, while adding for the
 application transparent libv4lconvert conversion where necessary.
 .
 This package contains the shared libraries.
Homepage: http://people.atrpms.net/~hdegoede/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug

Re: Donating a mr97310 based elta-media 8212dc (0x093a:0x010e)

[Thomas Kaiser]

On 05/01/2009 10:47 AM, Wolfram Sang wrote:

Thomas, is it okay for you, if I leave this to you?


Yes, I sent you my post address in private mail.
Lets see what I can find out with this cam ;-)

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

kilg...@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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gspca in the LinuxTv wiki

[Thomas Kaiser]

Paul Thomas wrote:

I like it. Can we add a section for tested architectures (i.e. x86,
x86_64, arm, sparc, etc...).


Hi Paul

I think this is welcome, when it starts

This is a suggestion, which does not mean that I do all the stuff.

I will get up the webcams from my page to the LinuxTv wiki with all 
information I can provide


But I hope other people will contribute, too?

Thomas



thanks,
Paul

On Mon, Mar 23, 2009 at 2:46 PM, Thomas Kaiser v...@kaiser-linux.li wrote:

I was thinking about updating my page [1] with the results I get with gspca
V2. But I think it would be better to have this info on the LinuxTV wiki.
Unfortunately, I did not find a page for gspca. So I thought I should start
one, but I don't think this is the right thing because there are other
drivers available for webcams.

Why not start a Webcam compatibly page similar to my page [1]?
- a photo of the webcam
- USB ID
- capabilities of the cam
- the chipsets when known
- driver + version (+ kernel version), at the time tested
- application used for testing (version)
- links with some information to other interesting pages
- and some more you can think of

What you guys think about it?


[1] http://www.kaiser-linux.li/index.php/Linux_and_Webcams

Thomas

PS: the only reference I found about gspca on the LinuxTV wiki:
http://www.linuxtv.org/wiki/index.php/Development:_Reverse_Engineering_USB_Webcams#gspca
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gspca in the LinuxTv wiki

[Thomas Kaiser]

Theodore Kilgore wrote:



On Mon, 23 Mar 2009, Thomas Kaiser wrote:



I was thinking about updating my page [1] with the results I get with 
gspca V2. But I think it would be better to have this info on the 
LinuxTV wiki. Unfortunately, I did not find a page for gspca. So I 
thought I should start one, but I don't think this is the right thing 
because there are other drivers available for webcams.


Why not start a Webcam compatibly page similar to my page [1]?
- a photo of the webcam
- USB ID
- capabilities of the cam
- the chipsets when known
- driver + version (+ kernel version), at the time tested
- application used for testing (version)
- links with some information to other interesting pages
- and some more you can think of

What you guys think about it?


[1] http://www.kaiser-linux.li/index.php/Linux_and_Webcams

Thomas


Your web page looks nice, as a start. But it is, like most web pages 
which deal with Linux support for category X, Y, or Z of hardware, not 
up to date. Goes with the territory, I guess.


That's the reason why I asked to do this on the LinuxTv wiki!



However, I do have one question. How are you going to list the various 
cameras?


I really don't know. But when we start a page on the LinuxTv wiki, this 
could be a start, or not?




Probably, one needs to list them by brand name and model and by USB ID, 
too, as Michel Xaard did with his list in the first place. But then it 
will become a mighty long list. For, the same camera gets recycled in 
lots of different brands and models. This is the kind of information 
which someone needs who is buying a camera, because the camera does not 
come with the USB ID printed on the outside of the package.


Looks like you don't get it. When we provide pictures of the cam with 
the corresponding ID's and a reverence which driver will work, the folks 
know what can work..


But OTOH this causes a problem, too, because the manufacturers of 
cameras (probably some of them are not exactly manufacturers but rather 
packagers) are switching the electronics inside the device any time they 
feel like it, or if they get a large quantity of chips at a good price, 
or whatever. I have seen it happen several times that a certain camera 
keeps the make and model, but it gets a new USB Vendor:Product number. 
And, worst of all, it may have previously been well supported but now it 
is not. Someone who goes and buys the camera based upon the make and 
model which are stencilled on the outside of the camera and printed on 
the packaging material can end up being stung.


So, contribute to the wiki and correct this!
When you see a model which look the same at you saw on that page and 
your cam does not work in the real live it could be possible that the 
manufacture of the cam changed the chipset.


Why not write this in the wiki? I ave the same came but it looks not to 
be the same you have?


Therefore, I would recommend that all possible ways to identify a 
camera, however insignificant those ways might appear to be, should be 
preserved.


When the driver of your webcam is included in the main branch od the 
kernel, then it just should work|


As one example of this kind of information, there is a cheap camera 
distributor in the US called sakar.com. Their cameras always come with a 
little, insignificant number on the outside of the package somewhere. It 
is usually five digits long, and is sometimes found associated with the 
UPC barcode on the package and is found nowhere else. If you want to 
know which camera it is, that number is essential. But it is too typical 
of all of us that we throw away things which appear insignificant. Who 
would think that the bubble-pack card which the camera is packaged in 
will contain information that can be obtained nowhere else, or otherwise 
only by good luck or by trial and error? But, alas, it is true.


Very specific example: The Sakar KidzCam (old version) was an SQ905 
camera and thus well supported. The Sakar KidzCam (new version) is a 
Jeilin JL2005B and uses a particularly nasty compression algorithm which 
has eluded all attempts to figure out. The packaging in the store looks 
identical for both of them. The cameras physically look identical. The 
only way you could tell them apart in the store is by those little 
bitty, insignificant-looking code numbers on the packaging material.


I could give several other examples, too.


Thedore

As far I did webcam development it was always re-engineering.
I offered always my help, did I not?

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Topro 6800 driver [JPEG decoding solved]

[Thomas Kaiser]

Thomas Kaiser wrote:

Hello Anders

Good news, I could decode a frame which I extracted from the usbsnoobs I 
did :-). See attached picture frame3-03.jpg. It uses the quality 0.


Your black frame you sent me gets now correctly decode, too (frameA-01.jpg)

I found the Huffman table in the Windoz driver file (TP6810.sys) at 
offset 0x2a59c. The QTable which I found in a text file on my Windoz box 
can be found in this driver file, also.


I attached some binary files which I used to build the 2 attached jpeg.

For example use:
cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin frame3-03.jpg
to make the picture frame3-03.jpg.

This information should the cam get going in Linux ;-)

Happy Hacking,

Thomas

PS: I sent this to the linux-media mail list, because somebody else is 
interested about this information, too.




Just some comments about the observation you made on the frame header:

ff d8 ff fe 28 3c 01

- Byte 6: Yes, it is the current quality setting
- Byte 4  5: I think it is related to resolution. My snoops were done with 
320x240 (0x141e) and Anders were made with 640x480 (0x283c), twice as big!
- The rest is static

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Topro 6800 driver [JPEG decoding solved]

[Thomas Kaiser]

Hello Anders

Good news, I could decode a frame which I extracted from the usbsnoobs I 
did :-). See attached picture frame3-03.jpg. It uses the quality 0.


Your black frame you sent me gets now correctly decode, too (frameA-01.jpg)

I found the Huffman table in the Windoz driver file (TP6810.sys) at 
offset 0x2a59c. The QTable which I found in a text file on my Windoz box 
can be found in this driver file, also.


I attached some binary files which I used to build the 2 attached jpeg.

For example use:
cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin frame3-03.jpg
to make the picture frame3-03.jpg.

This information should the cam get going in Linux ;-)

Happy Hacking,

Thomas

PS: I sent this to the linux-media mail list, because somebody else is 
interested about this information, too.


inline: frame3-03.jpginline: frameA-01.jpg

FFD8-Q0-320x240.bin
Description: Binary data


FFD8-Q0-640x480.bin
Description: Binary data


FFD8-Q1-320x280.bin
Description: Binary data


FFD8-Q1-640x480.bin
Description: Binary data


FFDA.bin
Description: Binary data


huffman1.bin
Description: Binary data


frame3-3.bin
Description: Binary data

Mail list, Is WIKI up to date?

[Thomas Kaiser]

Anders Blomdell wrote:

Thomas Kaiser wrote:

Hello Anders

You should send your messages to linux-me...@vger.kernel.org. 
video4linux-l...@redhat.com is deprecated. The new mail list for V4L is 
  linux-me...@vger.kernel.org.


I just send my reply by mistake to video4linux-l...@redhat.com because I 
just hit replay all without checking the Email address.

And so did I, got the wrong adress first time since I followed:

  http://www.linuxtv.org/v4lwiki/index.php/Main_Page

guess I can't expect Google to find the right page always...

/Anders



Looks like the WIKI page you found is not up to date.

Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Topro 6800 driver

[Thomas Kaiser]

Hello Anders

Anders Blomdell wrote:

Thomas Kaiser wrote:

  And a 640*480 image divided in 8*8 subframes gives (640*480/(8*8)) 1200
  subframes, so now the question is how much info about the Huffman 
table this

  gives us?

I think nothing :-( , but you found the MCUs :-) As it looks quite the 
same as on the PAC7311, why not just try the Huffman table from the PAC7311?

Which seems to be encoded in the stream and not defined in the sourcecode (but
I'm tired, so I might well be wrong). Do you think you could extract it somehow?


I think it should be in the gspca source or in the v4l_library? I didn't 
follow gspca code and v4l_library code lately. Anyway PAC7311 is working 
AFAIK.


I'll check and try.

Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Thomas Kaiser]

Hello Theodore

kilg...@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

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Thomas Kaiser]

kilg...@banach.math.auburn.edu wrote:


felling-feeling

spelling/writing error (I meant feeling)

Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Thomas Kaiser]

Hello Theodore

kilg...@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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Thomas Kaiser]

Thomas Kaiser wrote:

Hello Theodore

kilg...@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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Topro 6800 driver

[Thomas Kaiser]

Hello Anders

Anders Blomdell wrote:

Jean-Francois Moine wrote:

On Fri, 27 Feb 2009 23:15:54 +0100
About the JPEG images, the Huffman table is always the same 
Does this mean that it's the same for all JPEG images or only for one 
camera?


If it's the same for all images, it should mean that I have a way to 
determine how much I have to chop off after the 0xfffe tag (no illegal 
huffman codes - possibly chop at the correct position).


Comments anyone?



As per definition of JPEG, the Huffman table is always calculated 
especially for each picture to get the best compression. Thus the 
Huffman table and the DQT has to be in the JPEG stream like you see on 
JPEG picture on your HD.
With webcams, it is a bit an other story. The webcam hardware is usually 
not powerful enough to calculate the Huffman table for each frame. 
Therefor a static Huffman table is used. This Huffman table should fit 
more less to the image the camera is producing. With the drawback that 
we cannot achieve the highest compression possible. On the other hand 
the Huffman table is always the same the cam has not to send this in the 
video stream and the stream has less overhead.


In short, the Huffman table is always the same for a given webcam.

I don't think 0xfffe is a valid JPEG marker. 0xfffe is a comment marker 
and the next 2 bytes after this markers tells the length of the comment 
(including the two length byte). So, your comment would be 10300 Bytes 
long. I don't think that such many Bytes are used for a comment when 
they try to have as less as possible overhead.
I think 0xfffe is the start of the compressed data stream and has 
nothing to do with JPEG markers.


Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] How to pass camera Orientation to userspace

[Thomas Kaiser]

Also an overview is often very helpful. Also trying to visualize what 
might be needed in the future is helpful. All of this can be extremely 
helpful. But not everyone can see or imagine every possible thing. For 
example, it seems that some of the best minds in the business are 
stunned when confronted with the fact that some manufacturer of cheap 
electronics in Taiwan has produced a lot of mass-market cameras with 
the sensors turned upside down, along with some other cameras having 
the same USB ID with different sensors, which act a bit differently. 
Clearly, if such a thing happened once it can happen again. So how to 
deal with such a

problem?


Actually, this happens and is happening!

Just step back a get an other view.

These consumer products are manly produced for the Windoz audience.

After introduction of Win XP the consumer where told that USB device 
will run out of the box in Win XP, which is sometimes true, but .


But on all (Windowz) Webcams (are Linux Webcams available?) I buy, I 
find a sticker which tells me to first insert the driver CD before 
connecting the cam to the PC. When you do, like instructed, your cam 
works like you expected!


Evan the USB ID is the same like the other webcam from the other vendor, 
you are (more or less) forced to install the driver from this particular 
vendor, you get a new driver! Doesn't matter if the sensor is mounted 
upside down, the new driver takes care about this. So, it looks like 
the cam in the Windowz World just works because you were forced to 
install the driver from the CD.


So I guess the Windoz diver just knows more then the USB ID.

In the Linux World most of the drive are re-engineered, we don't know 
how to detect how the sensor is mounted, do we?


Actually, what I try to say, is that only the cam can know how the 
sensor is mounted. Thus, the kernel module has to provide this 
information to user space (by query the hardware).


The pivot is an other thing.

Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MR97310A and other image formats

[Thomas Kaiser]

kilg...@banach.math.auburn.edu wrote:



On Fri, 20 Feb 2009, Thomas Kaiser wrote:


kilg...@banach.math.auburn.edu wrote:



On Thu, 19 Feb 2009, Thomas Kaiser wrote:


kilg...@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

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MR97310A and other image formats

[Thomas Kaiser]

kilg...@banach.math.auburn.edu wrote:



On Fri, 20 Feb 2009, Thomas Kaiser wrote:


kilg...@banach.math.auburn.edu wrote:



On Fri, 20 Feb 2009, Thomas Kaiser wrote:


kilg...@banach.math.auburn.edu wrote:



On Thu, 19 Feb 2009, Thomas Kaiser wrote:


kilg...@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

Re: MR97310A and other image formats

[Thomas Kaiser]

kilg...@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 50standard 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 20another compression, used by one stillcam, not 
resolved
FF FF 00 FF 96 64 D0new 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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MR97310A and other image formats

[Thomas Kaiser]

kilg...@banach.math.auburn.edu wrote:



On Thu, 19 Feb 2009, Thomas Kaiser wrote:


kilg...@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 :-)


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MR97310A and other image formats

[Thomas Kaiser]

Jean-Francois Moine wrote:

On Tue, 17 Feb 2009 20:35:28 +0100
Thomas Kaiser v...@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

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PAC7302 disassembly

[Thomas Kaiser]

christopherwander...@columbus.rr.com wrote:
Can I get as much disassembly of the PAC7302 drivers with your comments next to 
it? I am trying to improve my webcam and currently disassembling the driver, in 
Vista64 with IDA Pro. (I still have the 32 bit driver files as I upgraded from 
xp32) 
I am helping on the gAIM/Pidgin voice/video chat and this driver isn't where I  
would like it to be. I need better color balance, even after changing alot of 
options I still turn out orange quite a bit. 
I have Assembly expierence, I own the Intel Instruction Manuals, so figuring out 
the actual given driver with a little bit of help based on the current progress 
should not be difficult 
Christopher W. Anderson 
--

To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Hello Christopher

Thanks for posting to linux-me...@vger.kernel.org.

As I wrote you back on the private mail you send me, I don't really 
understand what you try to tell or ask me!


What do you mean with disassembly? Converting the binary Windoz drive 
to assemble code? Or looking with a hex editor into the Windowz driver 
and figure out what the opcode is doing?


The PAC7302 Linux driver was develop by re-engineering the Windoz drive 
with the help of usb snoop. Usb snoop 
(http://benoit.papillault.free.fr/usbsnoop/) is a program which can log 
the usb traffic on a Windoz box. By looking at this logs, I could figure 
out how to control the cam (PAC7302 bridge). To find out the compression 
Pixart is using in this chip was a long journey, too.


I suggest you get the newest driver from linuxtv.org or from
Jean-Francois Moine site (http://moinejf.free.fr/).

Don't forget to get the newest libv4l lib from Hans de Geode. After you 
installed this and tested the webcam, please report back how the driver 
is working.


Anyway, when you are able to disassemble the Windowz drive, please post 
your results here. There are some people around here how can comment 
your outcome.


Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PAC7302 disassembly

[Thomas Kaiser]

Thomas Kaiser wrote:

christopherwander...@columbus.rr.com wrote:
Can I get as much disassembly of the PAC7302 drivers with your 
comments next to it? I am trying to improve my webcam and currently 
disassembling the driver, in Vista64 with IDA Pro. (I still have the 
32 bit driver files as I upgraded from xp32) I am helping on the 
gAIM/Pidgin voice/video chat and this driver isn't where I  would like 
it to be. I need better color balance, even after changing alot of 
options I still turn out orange quite a bit. I have Assembly 
expierence, I own the Intel Instruction Manuals, so figuring out the 
actual given driver with a little bit of help based on the current 
progress should not be difficult Christopher W. Anderson --

To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Hello Christopher

Thanks for posting to linux-me...@vger.kernel.org.

As I wrote you back on the private mail you send me, I don't really 
understand what you try to tell or ask me!


What do you mean with disassembly? Converting the binary Windoz drive 
to assemble code? Or looking with a hex editor into the Windowz driver 
and figure out what the opcode is doing?


The PAC7302 Linux driver was develop by re-engineering the Windoz drive 
with the help of usb snoop. Usb snoop 
(http://benoit.papillault.free.fr/usbsnoop/) is a program which can log 
the usb traffic on a Windoz box. By looking at this logs, I could figure 
out how to control the cam (PAC7302 bridge). To find out the compression 
Pixart is using in this chip was a long journey, too.


I suggest you get the newest driver from linuxtv.org or from
Jean-Francois Moine site (http://moinejf.free.fr/).

Don't forget to get the newest libv4l lib from Hans de Geode. After you 
installed this and tested the webcam, please report back how the driver 
is working.


Anyway, when you are able to disassemble the Windowz drive, please post 
your results here. There are some people around here how can comment 
your outcome.


Thomas

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Sorry for replying to my own post.

I forgot to tell that there is no documentation available from Pixart. I 
tried to meet them (Pixart) the last time I was in Taiwan but they 
refused to meet me :-( (Looks like they are not interested to have there 
products running with Linux)


Thomas


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html