Hi Filippo, On Wednesday 12 November 2008, Filippo Argiolas wrote: > On mer, 2008-11-12 at 02:03 +0100, Laurent Pinchart wrote: > > What do you mean by "something happens" ? Did the camera stop streaming ? > > I can't see any hint in the log. > > I mean that something not noticeable happens with the camera: everything > seems fine, I can see the video stream but any subsequent run of that > gst-launch command fails, hence I believe something happened in the > first run.
Or something doesn't happen in the second run. > I applied your patch in current svn (r262) and did the same test again. > Note that the second gst-launch run doesn't exit cleanly, I have to > press Ctrl+C 2 times, the first one tries to correctly stop the pipeline > but hangs, the second actually forces quit. Not really surprising, the driver waits in VIDIOC_DQBUF for a video buffer to be ready. This is supposed to be interruptible though. > The webcam light never turns on, maybe something is failing with webcam > initialization. I've compared the two traces (both kernel log messages and libv4l) and they are identical for the initialisation part. Two things bother me. First of all, libv4l spams the the driver (and thus the camera) with VIDIOC_TRY_FMT requests. Given the fragile state of many webcam firmwares, I wouldn't be surprised if some of them would simply crash. Then, and this might be the real issue here, the application calls VIDIOC_S_FMT but libv4l doesn't relay that to the driver. I suppose there's a check in the library that compares the requested format with the current format and returns immediately if they are identical. This means the camera doesn't receive any set format request between the two runs. I wouldn't be surprised if camera developers never expected that. As a quick workaround, could you please try the attached patch ? It modifies device initialisation to make sure a set format request is send right before starting the video stream. > Another thing, I'm a bit confused about the place uvcvideo development > is going on at the moment. I see you sent me a patch against svn but I > believed uvc was included upstream so development was going on on > linuxtv mercurial repos.. isn't it so? I'm moving from the SVN repository on Berlios to Mercurial on linuxtv.org. It was easier for me yesterday to generate the patch against SVN. Best regards, Laurent Pinchart
Index: uvc_video.c =================================================================== --- uvc_video.c (revision 163) +++ uvc_video.c (working copy) @@ -974,11 +974,8 @@ break; } - /* Commit the default settings. */ probe->bFormatIndex = format->index; probe->bFrameIndex = frame->bFrameIndex; - if ((ret = uvc_set_video_ctrl(video, probe, 0)) < 0) - return ret; video->streaming->cur_format = format; video->streaming->cur_frame = frame; @@ -1018,6 +1015,10 @@ if ((ret = uvc_queue_enable(&video->queue, 1)) < 0) return ret; + /* Commit the streaming parameters. */ + if ((ret = uvc_set_video_ctrl(video, &video->streaming->ctrl, 0)) < 0) + return ret; + return uvc_init_video(video, GFP_KERNEL); } Index: uvc_v4l2.c =================================================================== --- uvc_v4l2.c (revision 167) +++ uvc_v4l2.c (working copy) @@ -252,9 +252,6 @@ if (ret < 0) return ret; - if ((ret = uvc_commit_video(video, &probe)) < 0) - return ret; - memcpy(&video->streaming->ctrl, &probe, sizeof probe); video->streaming->cur_format = format; video->streaming->cur_frame = frame; @@ -315,10 +312,6 @@ if ((ret = uvc_probe_video(video, &probe)) < 0) return ret; - /* Commit the new settings. */ - if ((ret = uvc_commit_video(video, &probe)) < 0) - return ret; - memcpy(&video->streaming->ctrl, &probe, sizeof probe); /* Return the actual frame period. */
_______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
