Frame Error while streaming MJPEG

Aug 14, 2007 at 8:56 AM
Edited Aug 20, 2007 at 11:48 AM
Hello

I'm having a strange issue while streaming MJPEG-Video from a Quickcam pro 5000. In general, the driver works perfectly. However, as soon as I point the camera towards an object with many details (such as a fan with a metal grill for example), the driver repeatedly reports:
WebCam: === Frame Error !!! === Flags: cd

As long as I keep the camera pointed to the fan, no new frames are received from the camera (only Frame Errors). When I move the camera away and point it to my table for example, the stream resumes. If I keep the camera pointed to the fan and no new frames are received, the thread calling the driver stops waiting for new frames (Next Frame event not signaled). This problem only occures with a resolution of 640x480.

The Frame Error Message means, that the ERR-Bit in the MJPEG-Header is set. According to the USB Video Class Documentation, one can get a more specific error code via the Stream-Error-Code-Control. The driver seams to read this error code in the GetCameraError-Function, but it queries the Probe-Control (USB_VIDEO_VS_CS_PROBE_CTL) and not the Stream-Error-Code-Control (USB_VIDEO_VS_CS_STREAM_ERROR_CODE_CTL). Why is that?
Anyways, I also tried the Stream-Error-Code-Control and in both cases i read code 0: meaning no error.

Does anyone have an idea why the Error-Bit in the MJPEG-Header is set by the camera? Or how I can get details/error codes from the camera?
Has anyone ever encountered anything similar?

Thanks in advance
daniel
Sep 18, 2007 at 1:21 PM
Hi Daniel,

Did you fix this problem? I'm having similar issues (see discussion 'videostream 90% broken')

Thanks
Mark Bailey
Sep 20, 2007 at 2:47 PM
Hello Mark

Unfortunately i haven't found a solution. I checked again and under the above described circumstances, i sometimes also get a small grey bar at the bottom of the screen, as described in 'videostream 90% broken'.
I believe your guess that this is a timing issue could be right, although I don't understand why the camera gives a perfect image when connected to a PC. But maybe the logitech driver uses a whole different interface...

Daniel
Jun 6, 2008 at 3:33 PM
Hello Again,


Daniel's problem is causing me a major headache. As Daniel has mentioned, if the camera looks at a complicated image, such as a fine mesh, the camera will freeze and stop delivering frames.
I'm using a Logitech Pro 5000 (PID: 08C5 and 08CE) running at resolut 640x480. I can also reproduce the problem using AMCAP (with Logitech Drivers) on a old Windows 2000 machine, that only has USB 1.1.
As Daniel mentions lowering the resolution to 320x240 can almost solve the problem, but I can still get the camera to freeze. The problem is much worse on the older model of the camera (PID 08C5).

Looking at the code, the call to DeviceIOControl will timeout when the camera freezes. As Daniel has mentioned the problem must be in the camera itself, if the MJPEG frames have a error flag set.

I'd be grateful if any one could post to this discussion with any new information.


Thanks in advance
Mark Bailey


Jul 7, 2008 at 1:30 PM
Just an update:

I can reproduce the freezing problem on my XP machine. I just have to connect the QuickCam Pro 5000 to the PC via a USB 1.1 hub. Using Logitech's application software and driver, the camera will freeze when I point the camera to a fine grid pattern.
Interestingly the USB 1.1 hub on my CE board is the same type, a Texas Instruments TUSB2046 USB1.1. There is an issue with VIA usb hubs and webcams, but I've not seen any related issues to do with the TI hubs.

I've also connected a USB sniffer to the camera to see what happens when the camera freezes. During normal operation the sniffer will show a list of USB transactions containing packets of data. When the camera freezes, the usb sniffer reports 1000's of NAK (no acknowledgements) transactions.

I've also tried later Logitech Cameras: QCP 9000 and QC Communicate Deluxe, both also have the freezing problem.


Mark