Ok... digging still more into this problem that I'm *still* fighting, using mplayer and a higher debug level, what I *think* the significant message is (this is just one example line): libv4lconvert: Error decompressing JPEG: fill_nbits error: need 5 more bits fps = 15.626953, interval = 0.096001, a_skew = 0.000000, corr_skew = 0.000000 vcnt = 1, acnt = 0
Which seems to indicate that for some reason, on *some* hardware, libv4lconvert is doing something wrong that it did correctly in the last kernel.
Is anyone using an older USB webcam that can look at this issue? I can't really test it on our RHEL box (well, I suppose I could try) to put in a ticket with them.
This is CentOS 6.4, and it's current, 2.6.32-358.11.1.el6.x86_64 #1 SMP kernel.
mark
And in other news, Linus renames the current release, 3.11 kernel, Linux for Workgroups (for real)....
m.roth@5-cent.us wrote:
Ok... digging still more into this problem that I'm *still* fighting, using mplayer and a higher debug level, what I *think* the significant message is (this is just one example line): libv4lconvert: Error decompressing JPEG: fill_nbits error: need 5 more bits fps = 15.626953, interval = 0.096001, a_skew = 0.000000, corr_skew = 0.000000 vcnt = 1, acnt = 0
Which seems to indicate that for some reason, on *some* hardware, libv4lconvert is doing something wrong that it did correctly in the last kernel.
Is anyone using an older USB webcam that can look at this issue? I can't really test it on our RHEL box (well, I suppose I could try) to put in a ticket with them.
This is CentOS 6.4, and it's current, 2.6.32-358.11.1.el6.x86_64 #1 SMP kernel.
One followup bit: before I run mplayer, I did export LD_PRELOAD=/usr/lib64/libvdpau.so.1:/usr/lib64/libv4l/v4l2convert.so and I get the top 10%-15% ok, and the rest of the window green. If I use export LD_PRELOAD=/usr/lib64/libvdpau.so.1:/usr/lib64/libv4l/v4lconvert.so I get only the outline of the window, and *nothing* inside, which seems to me to indicate it's that library, not the gspca driver.
An additional, and I *think* related datapoint: after the kernel upgrade, one of my user's website, which has a wiki, and that has a page that creates thumbnails of jpgs failed, though I believe he said he could do it from a command line, using /usr/bin/convert; how the website did it, I'm not sure... but I *do* see that ldd tells me that convert is linked to both v4lconvert.so and v4l2convert.so.
mark
m.roth@5-cent.us wrote:
m.roth@5-cent.us wrote:
Ok... digging still more into this problem that I'm *still* fighting, using mplayer and a higher debug level, what I *think* the significant message is (this is just one example line): libv4lconvert: Error decompressing JPEG: fill_nbits error: need 5 more bits fps = 15.626953, interval = 0.096001, a_skew = 0.000000, corr_skew = 0.000000 vcnt = 1, acnt = 0
Which seems to indicate that for some reason, on *some* hardware, libv4lconvert is doing something wrong that it did correctly in the last kernel.
Is anyone using an older USB webcam that can look at this issue? I can't really test it on our RHEL box (well, I suppose I could try) to put in a ticket with them.
This is CentOS 6.4, and it's current, 2.6.32-358.11.1.el6.x86_64 #1 SMP kernel.
One followup bit: before I run mplayer, I did export LD_PRELOAD=/usr/lib64/libvdpau.so.1:/usr/lib64/libv4l/v4l2convert.so and I get the top 10%-15% ok, and the rest of the window green. If I use export LD_PRELOAD=/usr/lib64/libvdpau.so.1:/usr/lib64/libv4l/v4lconvert.so I get only the outline of the window, and *nothing* inside, which seems to me to indicate it's that library, not the gspca driver.
An additional, and I *think* related datapoint: after the kernel upgrade, one of my user's website, which has a wiki, and that has a page that creates thumbnails of jpgs failed, though I believe he said he could do it from a command line, using /usr/bin/convert; how the website did it, I'm not sure... but I *do* see that ldd tells me that convert is linked to both v4lconvert.so and v4l2convert.so.
Ok, following myself up (I've not seen any responses - is anyone listening?)... yesterday, right before I left, I got the camera working. However... it only works in 320x240 mode. In 640x480, it's still mostly green. Based on this, I've decided my previous analysis was wrong, and the real clue were the error messages about "not enough bandwidth". What I now think is that someone made a change to the USB driver for the oldest, 1.0 and 1.1 specs, and it only hits with certain onboard chips - nothing else can explain why it runs on similar but not identical hardware, running the same version of the o/s.
mark
Hi Mark,
On 07/17/2013 03:24 PM, m.roth@5-cent.us wrote:
Ok, following myself up (I've not seen any responses - is anyone listening?)...
Yes, I've read every email you have sent on the subject. Unfortunatly I have no clue.
yesterday, right before I left, I got the camera working. However... it only works in 320x240 mode. In 640x480, it's still mostly green. Based on this, I've decided my previous analysis was wrong, and the real clue were the error messages about "not enough bandwidth". What I now think is that someone made a change to the USB driver for the oldest, 1.0 and 1.1 specs, and it only hits with certain onboard chips - nothing else can explain why it runs on similar but not identical hardware, running the same version of the o/s.
I only have a gspca webcam in my laptop and it's broken so I can't really be of much help. The only thing I recall is that it did not work very well with Fedora. Usually I had to grab the upstream gspca driver, mess with some defines to get the colors right, compile it and keep fingers crossed when inserting the module and starting cheese. The laptop's USB version is USB1 and it has a NM10/ICH7 chipset.
FWIW, maybe try every older kernel you can get your hands on and see where the issue no longer occurs. Then get the kernel's src.rpm and try to figure out which patch could possibly be the culprit.
Regards, Patrick
Hi, Patrick,
Patrick Lists wrote:
On 07/17/2013 03:24 PM, m.roth@5-cent.us wrote:
Ok, following myself up (I've not seen any responses - is anyone listening?)...
Yes, I've read every email you have sent on the subject. Unfortunatly I have no clue.
Thanks for listening, at least. Weeks of googling and screwing around gets *really* tiring and frustrating.
yesterday, right before I left, I got the camera working. However... it only works in 320x240 mode. In 640x480, it's still mostly green. Based on this, I've decided my previous analysis was wrong, and the real clue were the error messages about "not enough bandwidth". What I now think is that someone made a change to the USB driver for the oldest, 1.0 and 1.1 specs, and it only hits with certain onboard chips - nothing else can explain why it runs on similar but not identical hardware,
running
the same version of the o/s.
I only have a gspca webcam in my laptop and it's broken so I can't really be of much help. The only thing I recall is that it did not work
Ah. Y'know, you can pick up the things really cheaply - I think we got a bunch of these little cameras a few years before I started here, and *then* they were something like $10 or $20 each.
very well with Fedora. Usually I had to grab the upstream gspca driver, mess with some defines to get the colors right, compile it and keep fingers crossed when inserting the module and starting cheese. The laptop's USB version is USB1 and it has a NM10/ICH7 chipset.
Have you tried playing with the parms in your viewer? You might not need to recompile. And we're really trying *not* to build our own packages.
FWIW, maybe try every older kernel you can get your hands on and see where the issue no longer occurs. Then get the kernel's src.rpm and try to figure out which patch could possibly be the culprit.
Can't do things like that, not without a show stopper: these are servers here at work, and they *must* stay up as much as possible.
mark
Hi Mark,
On 07/17/2013 05:11 PM, m.roth@5-cent.us wrote:
Hi, Patrick,
Patrick Lists wrote:
On 07/17/2013 03:24 PM, m.roth@5-cent.us wrote:
Ok, following myself up (I've not seen any responses - is anyone listening?)...
Yes, I've read every email you have sent on the subject. Unfortunatly I have no clue.
Thanks for listening, at least. Weeks of googling and screwing around gets *really* tiring and frustrating.
I can imagine.
yesterday, right before I left, I got the camera working. However... it only works in 320x240 mode. In 640x480, it's still mostly green. Based on this, I've decided my previous analysis was wrong, and the real clue were the error messages about "not enough bandwidth". What I now think is that someone made a change to the USB driver for the oldest, 1.0 and 1.1 specs, and it only hits with certain onboard chips - nothing else can explain why it runs on similar but not identical hardware,
running
the same version of the o/s.
I only have a gspca webcam in my laptop and it's broken so I can't really be of much help. The only thing I recall is that it did not work
Ah. Y'know, you can pick up the things really cheaply - I think we got a bunch of these little cameras a few years before I started here, and *then* they were something like $10 or $20 each.
This built-in gspca webcam is the only one I've had problems with. The more expensive Logitech ones always worked fine for me.
very well with Fedora. Usually I had to grab the upstream gspca driver, mess with some defines to get the colors right, compile it and keep fingers crossed when inserting the module and starting cheese. The laptop's USB version is USB1 and it has a NM10/ICH7 chipset.
Have you tried playing with the parms in your viewer? You might not need to recompile. And we're really trying *not* to build our own packages.
The laptop just got a fresh F19 install. I just wiggled the webcam after starting Cheese and to my astonishment the green led lit up and Cheese showed something. The pic was very bad, interlaced and it seems to copy everything 3 times horizontally while overlapping those images. I set it to 320x240 and no change. So also in F19 at least my gspca webcam is not working very well.
FWIW, maybe try every older kernel you can get your hands on and see where the issue no longer occurs. Then get the kernel's src.rpm and try to figure out which patch could possibly be the culprit.
Can't do things like that, not without a show stopper: these are servers here at work, and they *must* stay up as much as possible.
Understand. The only reason I suggested it is that if you figure out which patch causes the issue that you could then file a BZ so that it might get fixed.
Regards, Patrick
Patrick Lists wrote:
On 07/17/2013 05:11 PM, m.roth@5-cent.us wrote:
Patrick Lists wrote:
On 07/17/2013 03:24 PM, m.roth@5-cent.us wrote:
<snip>
I only have a gspca webcam in my laptop and it's broken so I can't really be of much help. The only thing I recall is that it did not work
Ah. Y'know, you can pick up the things really cheaply - I think we got a bunch of these little cameras a few years before I started here, and *then* they were something like $10 or $20 each.
This built-in gspca webcam is the only one I've had problems with. The more expensive Logitech ones always worked fine for me.
<snip>
The laptop just got a fresh F19 install. I just wiggled the webcam after
Well, the redhat list would be a better place to discuss that... but FC19 was just released. As I said to my manager's student, unless you *really* want to be an alpha or early beta tester, don't *EVER* install release x.0, always wait for at least x.01 or x.1....
starting Cheese and to my astonishment the green led lit up and Cheese showed something. The pic was very bad, interlaced and it seems to copy
Interlaced is usually a parameter you can change in a config option.
everything 3 times horizontally while overlapping those images. I set it to 320x240 and no change. So also in F19 at least my gspca webcam is not working very well.
Which gspca driver is installed (lsmod | grep gspca)? And it might require exporting LD_PRELOAD with v4lcompat.so or v4l2convert.so.
mark
mark
On 07/17/2013 05:40 PM, m.roth@5-cent.us wrote: [snip]
Which gspca driver is installed (lsmod | grep gspca)? And it might require exporting LD_PRELOAD with v4lcompat.so or v4l2convert.so.
It's the gspca_vc032x module. LD_PRELOADING either lib did not make a difference and Cheese spits out an internal data flow error when started from the CLI.
From digging in my mail archives the error in /var/log/messages was:
Jan 3 17:37:10 luna kernel: [ 7358.087971] gspca: ISOC data error: [62] len=0, status=-71
That was on Fedora 14 with kernel 2.6.35.10-74.fc14.x86_64 and the id of the webcam is: Logitech Orbicam 046d:0896
The patch that fixed it is:
$ cat gspca-sensor.patch diff -uNr gspca-2.13.3.org/build/vc032x.c gspca-2.13.3/build/vc032x.c --- gspca-2.13.3.org/build/vc032x.c 2011-01-15 09:46:40.000000000 +0100 +++ gspca-2.13.3/build/vc032x.c 2011-07-28 18:16:41.138640918 +0200 @@ -3716,9 +3716,9 @@
sensor = vc032x_probe_sensor(gspca_dev); //vish -// if (sd->sensor == SENSOR_POxxxx -// && sensor == SENSOR_PO3130NC) -// sensor = sd->sensor; + if (sd->sensor == SENSOR_POxxxx + && sensor == SENSOR_PO3130NC) + sensor = sd->sensor;
switch (sensor) { case -1:
Regards, Patrick
Patrick Lists wrote:
On 07/17/2013 05:40 PM, m.roth@5-cent.us wrote: [snip]
Which gspca driver is installed (lsmod | grep gspca)? And it might require exporting LD_PRELOAD with v4lcompat.so or v4l2convert.so.
It's the gspca_vc032x module. LD_PRELOADING either lib did not make a difference and Cheese spits out an internal data flow error when started from the CLI.
Have you tried with mplayer? Do the export, then: mplayer tv:// -tv driver=v4l2:device=/dev/video0:width=320:height=240
and see what you see. The idea is to try a different viewer.
From digging in my mail archives the error in /var/log/messages was:
Jan 3 17:37:10 luna kernel: [ 7358.087971] gspca: ISOC data error: [62] len=0, status=-71
That was on Fedora 14 with kernel 2.6.35.10-74.fc14.x86_64 and the id of the webcam is: Logitech Orbicam 046d:0896
The patch that fixed it is:
$ cat gspca-sensor.patch diff -uNr gspca-2.13.3.org/build/vc032x.c gspca-2.13.3/build/vc032x.c --- gspca-2.13.3.org/build/vc032x.c 2011-01-15 09:46:40.000000000 +0100 +++ gspca-2.13.3/build/vc032x.c 2011-07-28 18:16:41.138640918 +0200 @@ -3716,9 +3716,9 @@
sensor = vc032x_probe_sensor(gspca_dev); //vish -// if (sd->sensor == SENSOR_POxxxx -// && sensor == SENSOR_PO3130NC) -// sensor = sd->sensor;
if (sd->sensor == SENSOR_POxxxx
&& sensor == SENSOR_PO3130NC)sensor = sd->sensor;switch (sensor) { case -1:
Hmmmm, I'm a bit confused: it looks as though the commented out lines are identical to the new lines; and as there's no + in front of it, it looks as though the statement to set sensor was there before... so I don't get the difference.
I do get the logic: probe the sensor, and if it says it's this, then reset it to that.
mark
On 07/17/2013 06:54 PM, m.roth@5-cent.us wrote: [snip]
Have you tried with mplayer? Do the export, then: mplayer tv:// -tv driver=v4l2:device=/dev/video0:width=320:height=240
Mplayer complained about some missing vdpau lib so that did not work out but I tried svv from moinejf.free.fr and got the same results as previously described.
and see what you see. The idea is to try a different viewer.
From digging in my mail archives the error in /var/log/messages was:
Jan 3 17:37:10 luna kernel: [ 7358.087971] gspca: ISOC data error: [62] len=0, status=-71
That was on Fedora 14 with kernel 2.6.35.10-74.fc14.x86_64 and the id of the webcam is: Logitech Orbicam 046d:0896
The patch that fixed it is:
$ cat gspca-sensor.patch diff -uNr gspca-2.13.3.org/build/vc032x.c gspca-2.13.3/build/vc032x.c --- gspca-2.13.3.org/build/vc032x.c 2011-01-15 09:46:40.000000000 +0100 +++ gspca-2.13.3/build/vc032x.c 2011-07-28 18:16:41.138640918 +0200 @@ -3716,9 +3716,9 @@
sensor = vc032x_probe_sensor(gspca_dev);//vish -// if (sd->sensor == SENSOR_POxxxx -// && sensor == SENSOR_PO3130NC) -// sensor = sd->sensor;
if (sd->sensor == SENSOR_POxxxx
&& sensor == SENSOR_PO3130NC)sensor = sd->sensor;switch (sensor) { case -1:
Hmmmm, I'm a bit confused: it looks as though the commented out lines are identical to the new lines; and as there's no + in front of it, it looks as though the statement to set sensor was there before... so I don't get the difference.
I can see the plusses fine but maybe something got mangled so here's what is prepended with a "+":
if (sd->sensor == SENSOR_POxxxx sensor == SENSOR_PO3130NC) sensor = sd->sensor;
Just checked git.linuxtv.org where the latest vc032x.c code lives and it has changed such that this patch no longer applies. My C foo is not at kernel driver level so I'll leave it at that and just use one of the webcams in my bag.
Regards, Patrick
Patrick Lists wrote:
On 07/17/2013 06:54 PM, m.roth@5-cent.us wrote: [snip]
Have you tried with mplayer? Do the export, then: mplayer tv:// -tv driver=v4l2:device=/dev/video0:width=320:height=240
Mplayer complained about some missing vdpau lib so that did not work out but I tried svv from moinejf.free.fr and got the same results as previously described.
Yeah, that's annoying. I solved it by export LD_PRELOAD=/usr/lib64/libvdpau.so.1:/usr/lib64/libv4l/v4l2convert.so
and see what you see. The idea is to try a different viewer.
From digging in my mail archives the error in /var/log/messages was:
Jan 3 17:37:10 luna kernel: [ 7358.087971] gspca: ISOC data error: [62] len=0, status=-71
That was on Fedora 14 with kernel 2.6.35.10-74.fc14.x86_64 and the id of the webcam is: Logitech Orbicam 046d:0896
The patch that fixed it is:
$ cat gspca-sensor.patch diff -uNr gspca-2.13.3.org/build/vc032x.c gspca-2.13.3/build/vc032x.c --- gspca-2.13.3.org/build/vc032x.c 2011-01-15 09:46:40.000000000 +0100 +++ gspca-2.13.3/build/vc032x.c 2011-07-28 18:16:41.138640918 +0200 @@ -3716,9 +3716,9 @@
sensor = vc032x_probe_sensor(gspca_dev);//vish -// if (sd->sensor == SENSOR_POxxxx -// && sensor == SENSOR_PO3130NC) -// sensor = sd->sensor;
if (sd->sensor == SENSOR_POxxxx
&& sensor == SENSOR_PO3130NC)sensor = sd->sensor;switch (sensor) { case -1:
Hmmmm, I'm a bit confused: it looks as though the commented out lines are identical to the new lines; and as there's no + in front of it, it looks as though the statement to set sensor was there before... so I don't get the difference.
I can see the plusses fine but maybe something got mangled so here's what is prepended with a "+":
if (sd->sensor == SENSOR_POxxxx sensor == SENSOR_PO3130NC) sensor = sd->sensor;
Just checked git.linuxtv.org where the latest vc032x.c code lives and it has changed such that this patch no longer applies. My C foo is not at kernel driver level so I'll leave it at that and just use one of the webcams in my bag.
Sorry I couldn't help more.
mark
-
m.roth＠5-cent.us -
Patrick Lists