Hi, Thanks for your fast answer ! The QBUF/DQBUF bug is fixed in CVS. Actually in 1.5.1 the v4lv2 support was still under development and testing, that's why it was not enabled by default. the Xsync message traduces a segmentation fault: executing from gdb should show the backtrace. Unfortunately I don't reproduce that problem, if after upgrading to cvs you can do it with gdb I 'll fix it.
It appears the bug never produces at linphone startup. Actually linphone closes/reopen the device for each new call and for each inter call duration where only local preview is enabled. I wonder whether those fast close/reopen events do not disturb the driver or the camera. The luvcview program works perfectly but I think it opens the device only once. I 'm still looking for a bug in linphone code... I'll try YUV but it 's not as simple as MJPEG for me for design reasons. If it were planar YUV (ideally YUV420P) it would be easy but it seems the driver (or the camera) only accepts a packed YUV format. Simon Le jeudi 7 décembre 2006 16:30, Martin Rubli a écrit : > Hi Simon, > > I did a little testing with linphone. I downloaded 1.5.1 and enabled > HAVE_LINUX_VIDEODEV2_H by hand. Is that supposed to be this way? (In the > future, please specify the version you work with.) > > After I got it running I had very different runs: > > 1. Sometimes it worked fine, the video seemed okay, no errors, etc. I > still got a lot of errors, though. See trace 1 (taken with --verbose) > below. > > 2. Usually when I ran it without --verbose it crashed when I enabled video > with "Xlib: unexpected async reply (sequence 0x3a12)!" (different numbers > each time). It crashed more often than not but for the times it didn't, > the traces looked like trace 2 below. > > 3. One time I was able to reproduce the screwed up pictures you mentioned. > IIRC --verbose was disabled. > > My ideas: > > I would first try to analyze where the "VIDIOC_QBUF failed: Invalid > argument" comes from. Something's really wrong there. > > Also, the Xlib errors you get, the different behavior with --verbose > enabled/disabled, as well as the screwed up picture might hint at some > synchronization issues in your program. I've seen those in the past when I > wrote webcam software. > > It's unlikely that the errors you see are actually the camera's fault. The > "EOF in empty packet." are harmless and if you use a newer driver version, > they shouldn't appear anymore (except in debug mode, but as I mentioned, > that's harmless). > > If you really think the MJPEG stream is broken, try to use the YUV mode > instead and see what it gives you. If your picture has green areas or > spots, the data gets corrupted somewhere. > > Cheers, > Martin > > > *** Trace 1 ********************************** > > ortp-message-v4l_start: open, fd=28 > ortp-message-v4lv2: MJPEG choosen > ortp-message-ms_filter_link: MSV4l:0x81dad40,0-->MSMJpegDec:0x81f91f0,0 > ortp-message-ms_filter_link: MSMJpegDec:0x81f91f0,0-->MSSdlOut:0x81e46b0,0 > ortp-message-v4l_thread starting > ortp-warning-VIDIOC_QBUF failed: Invalid argument > ortp-warning-VIDIOC_QBUF failed: Invalid argument > ortp-warning-VIDIOC_QBUF failed: Invalid argument > [mjpeg @ 0xb6c9d9a8]only 8 bits/component accepted > ortp-warning-ms_AVdecoder_process: error -1. > ortp-warning-VIDIOC_QBUF failed: Invalid argument > ortp-warning-VIDIOC_QBUF failed: Invalid argument > ortp-message-Using yuv overlay. > ortp-message-YUV overlay using hardware acceleration. > ortp-warning-We are late of 73 miliseconds. > [mjpeg @ 0xb6c9d9a8]only 8 bits/component accepted > ortp-warning-ms_AVdecoder_process: error -1. > ortp-warning-VIDIOC_QBUF failed: Invalid argument > ortp-warning-VIDIOC_QBUF failed: Invalid argument > [mjpeg @ 0xb6c9d9a8]mjpeg: unsupported coding type (cf) > [mjpeg @ 0xb6c9d9a8]invalid id 255 > ortp-warning-ms_AVdecoder_process: error -1. > ortp-warning-VIDIOC_QBUF failed: Invalid argument > ortp-warning-VIDIOC_QBUF failed: Invalid argument > [mjpeg @ 0xb6c9d9a8]only 8 bits/component accepted > ortp-warning-ms_AVdecoder_process: error -1. > ortp-warning-VIDIOC_QBUF failed: Invalid argument > ortp-warning-VIDIOC_QBUF failed: Invalid argument > > > *** Trace 2 ********************************** > > [mjpeg @ 0xb6cc49a8]invalid id 255 > [mjpeg @ 0xb6cc49a8]only 8 bits/component accepted > [mjpeg @ 0xb6cc49a8]invalid id 255 > [mjpeg @ 0xb6cc49a8]only 8 bits/component accepted > [mjpeg @ 0xb6cc49a8]invalid id 255 > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]mjpeg: unsupported coding type (c8) > [mjpeg @ 0xb6cc49a8]huffman table decode error > [mjpeg @ 0xb6cc49a8]invalid id 255 > [mjpeg @ 0xb6cc49a8]only 8 bits/component accepted > [mjpeg @ 0xb6cc49a8]invalid id 255 > [mjpeg @ 0xb6cc49a8]only 8 bits/component accepted > [mjpeg @ 0xb6cc49a8]invalid id 255 > [mjpeg @ 0xb6cc49a8]only 8 bits/component accepted > [mjpeg @ 0xb6cc49a8]invalid id 255 > [mjpeg @ 0xb6cc49a8]only 8 bits/component accepted > > > > On Thu, 07 Dec 2006 14:31:16 +0100, Simon Morlat > > <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I've bought a Logitech Quickcam Pro 5000 (Bus 004 Device 003: ID > > 046d:08c5 > > Logitech, Inc.), and I've got some problems with it and the uvc driver. > > I use linphone (a sip video phone I'm the maintainer). The picture is > > grabbed > > using mmap v4lv2 standart method with MJPEG format, then passed to > > ffmpeg to > > decode it as YUV420P and then displayed. > > > > Sometimes (quite often), it works well. > > Sometimes, despite pictures display correctly, ffmpeg complains with > > those > > warnings: > > > > [mjpeg @ 0xb6c8e9a8]mjpeg: unsupported coding type (c7) > > [mjpeg @ 0xb6c8e9a8]mjpeg: unsupported coding type (c6) > > > > [mjpeg @ 0xb6c8e9a8]picture size invalid (62975x62965) > > [mjpeg @ 0xb6c8e9a8]picture size invalid (62975x62965) > > > > [mjpeg @ 0xb6c8e9a8]huffman table decode error > > > > [mjpeg @ 0xb6c689a8]mjpeg: unsupported coding type (cf) > > [mjpeg @ 0xb6c689a8]invalid id 224 > > > > > > That seems to indicate that there is something corrupted in the MJPEG > > bitstream. > > > > And finally sometimes the picture are completely mixed, look for example > > this > > one: > > http://simon.morlat.free.fr/pro5000bug.jpg > > The frontiers between image parts are constantly and quicly moving. > > I saw on the mailing list that I was not the only one having this > > problem. > > > > As I'm also suspecting a problem with my code, I tried with xawtv, but > > unfortunately it fails and display nothing (for other reasons): > > > > This is xawtv-3.95, running on Linux/i686 (2.6.18-fm) > > WARNING: Your X-Server has no DGA support. > > /dev/video0 [v4l2]: no overlay support > > v4l-conf had some trouble, trying to continue anyway > > Warning: Cannot convert string > > "-*-ledfixed-medium-r-*--39-*-*-*-c-*-*-*" to > > type FontStruct > > ioctl: VIDIOC_G_STD(std=0xbffd1744 > > [PAL_G,PAL_D1,PAL_M,PAL_N,PAL_Nc,NTSC_M,SECAM_B,SECAM_G,SECAM_H,SECAM_K,S > >ECAM_K1,SECAM_L,?ATSC_8_VSB,ATSC_16_VSB, > > (null),(null),(null),(null),(null),(null)]): Argument invalide > > ioctl: VIDIOC_S_STD(std=0x0 []): Argument invalide > > ioctl: VIDIOC_DQBUF(index=0;type=VIDEO_CAPTURE;bytesused=0;flags=0x0 > > [];field=ANY;;timecode.type=0;timecode.flags=0;timecode.frames=0;timecode > >.seconds=0;timecode.minutes=0;timecode.hours=0;timecode.userbits="";sequen > >ce=0;memory=unknown): Argument invalide > > > > Maybe you have other suggestion of a working v4lv2 compatible viewer ? > > > > I used the uvc driver from svn (updated yesterday), compiled for 2.6.18 > > kernel. > > In dmesg, I have thoses messages: > > EOF in empty packet. > > EOF in empty packet. > > EOF in empty packet. > > > > I'm not sure they are related with uvc driver. > > > > Thanks for your help, tell me if you need more information. > > > > Simon > > _______________________________________________ > > Linux-uvc-devel mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/linux-uvc-devel _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
