On Mon, Mar 28, 2011 at 5:36 AM, Alexey Fisher <bug-tr...@fisher-privat.net> wrote:
> The reason can be... lost packets by usb controller... or may be camera > send only this parts... or hmm... You seem to be suggesting some hardware problem or a defect with the camera? This seems very unlikely to me: recall the camera seems to works "out of the box" with cheese, camorama, xawtv, camstream, guvcview. Only with skype and in some cases with luvcview do I get this distorted pattern, which is the same sort of pattern subjectively that I get when I run the gstreamer pipeline without the conversion element in it. I also have now tested in in Windows 7 and it seems to work fine there "out of the box" as well. > Can you please attach dmesg with trace, to enable trace you need: > sudo rmmod uvcvideo && sudo modprobe uvcvideo trace=0xffff Don't know quite what you mean? dmesg output during what? I attached the dmesg output when the camera is plugged in, followed by two runs of luvcview (the first two command lines below). I Except I edited out huge amounts of these lines throughout (which are very suggestive of a format mismatch as well): "uvcvideo: Dropping payload (out of sync)." > Can you please also try different frame rates with yuv. Yes, before, per instruction, I used the default. But I now find that lucview gives nice looking results for any frame rate above 17. In other words, luvcview -f yuv -s 320x240 -d /dev/video1 -i 17 does not work, but luvcview -f yuv -s 320x240 -d /dev/video1 -i 18 luvcview -f yuv -s 320x240 -d /dev/video1 -i 19 etc all do work. > Your gstreamer workaround probably grubs jpg stream from the cam. Yes, in more detail I speculate it goes like this: I have not yet tried to find the basic API for using webcams, but I assume the following are true: 1) uvc webcams can produce various streaming output formats in addition to different frame rates and frame sizes. 2) mine can produce at least two, a yuv kind and a jmpg kind 3) it produces jmpg by default (at least v4l2src puts that out) 4) all modern programs either set the format and then use the correct one, or take the default, detect it, and do the right thing 5) skype and luvciew, two old programs not modified for a long time, do not do this successfully in many, or all, cases. Skype in particular just takes what it gets and assumes it is in yuv format. (Although the luvcview runs from the dmesg seem to find the camera producing yuv format...) I will fiddle around with this more myself, to see what happens in dmesg when skype tries to use the camera for example. > The answer to your previous question: IMHO, if you can return this cam, > do it. UVC should just work. Unfortunately it is difficult to return it, there would be a restocking fee, and I am not even confident that I would not have similar issues or worse with other cameras. So if I can be assured it is reasonably okay to do things this way, I will just do them this way for now. As I understand the concept "UVC should just work", that means that if UVC is implemented totally correctly, then a UVC camera should "just work". But we don't know that UVC is implemented perfectly in Linux right now. Again, camera seems to work with almost all programs available on Linux, and works in Windows too. Perhaps the camera is doing something wrong, but it seems like it could be a simple miscommunication of format information easily bypassed with a small hack.
dmesg
Description: Binary data
_______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
