[CentOS] Back to gspca - semi-[SOLVED]

Wed Jul 17 13:24:44 UTC 2013
m.roth at 5-cent.us <m.roth at 5-cent.us>

m.roth at 5-cent.us wrote:
> m.roth at 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