High resolution issues with Logitech E3500 via mjpg_streamer

[xyz]

Logitech E3500 seems to output 176x144 YUV cleanly (via mjpg_streamer). However, better resolutions like 320x240 or 640x480 end up with incompatible MJPG.
Could anybody help with ideas? Should I blame the webcam or the mjpg_streamer?

I am testing E3500 (id 046d:09a4) on Debian Etch, which is updated to test and unstable. The camera itself is recognized well:

Code: Select all

Nov 21 01:01:11 cam kernel: [  113.750005] usb 2-2.2: new full speed USB device using uhci_hcd and address 3
Nov 21 01:01:12 cam kernel: [  113.976940] usb 2-2.2: configuration #1 chosen from 1 choice
Nov 21 01:01:12 cam kernel: [  113.982660] usb 2-2.2: New USB device found, idVendor=046d, idProduct=09a4
Nov 21 01:01:12 cam kernel: [  113.982770] usb 2-2.2: New USB device strings: Mfr=0, Product=0, SerialNumber=2
Nov 21 01:01:12 cam kernel: [  113.982857] usb 2-2.2: SerialNumber: 0BB31220
Nov 21 01:01:12 cam kernel: [  114.720852] Linux video capture interface: v2.00
Nov 21 01:01:12 cam kernel: [  114.896233] uvcvideo: Found UVC 1.00 device <unnamed> (046d:09a4)
Nov 21 01:01:12 cam kernel: [  114.912015] input: UVC Camera (046d:09a4) as /class/input/input5
Nov 21 01:01:12 cam kernel: [  114.912015] usbcore: registered new interface driver snd-usb-audio
Nov 21 01:01:12 cam kernel: [  114.917611] usbcore: registered new interface driver uvcvideo
Nov 21 01:01:12 cam kernel: [  114.917721] USB Video Class driver (v0.1.0)

But now begin the fun. 176x144 mode works OK but in YUV only. It really works which means that even ZM is able to get the stream.

Code: Select all

cam:~#  mjpg_streamer  -i "input_uvc.so -r 320x240 -y  -f 1  -d /dev/video0" -o "output_http.so -p 8080"
MJPG Streamer Version.: 2.0
 i: Using V4L2 device.: /dev/video0
 i: Desired Resolution: 320 x 240
 i: Frames Per Second.: 1
 i: Format............: YUV
 i: JPEG Quality......: 80
 format asked unavailable get width 176 height 144
 o: www-folder-path...: disabled
 o: HTTP TCP port.....: 8080
 o: username:password.: disabled
 o: commands..........: enabled

Now the centerpiece. Yes, it is perfectly possible to configure the E300 for modes 320x240 and 640x480. The known fact for UVC cameras seems to be that better resolutions will dictate MJPG mode. Never mind:

Code: Select all

Nov 21 01:27:16 cam MJPG-streamer [3128]: starting application
Nov 21 01:27:16 cam MJPG-streamer [3128]: enabling daemon mode
Nov 21 01:27:16 cam MJPG-streamer [3130]: MJPG Streamer Version.: 2.0
Nov 21 01:27:16 cam MJPG-streamer [3130]: Using V4L2 device.: /dev/video0
Nov 21 01:27:16 cam MJPG-streamer [3130]: Desired Resolution: 320 x 240
Nov 21 01:27:16 cam MJPG-streamer [3130]: Frames Per Second.: 6
Nov 21 01:27:16 cam MJPG-streamer [3130]: Format............: MJPEG
Nov 21 01:27:16 cam MJPG-streamer [3130]: www-folder-path...: disabled
Nov 21 01:27:16 cam MJPG-streamer [3130]: HTTP TCP port.....: 8080
Nov 21 01:27:16 cam MJPG-streamer [3130]: username:password.: disabled
Nov 21 01:27:16 cam MJPG-streamer [3130]: commands..........: enabled
Nov 21 01:27:16 cam MJPG-streamer [3130]: starting input plugin
Nov 21 01:27:16 cam MJPG-streamer [3130]: starting output plugin: output_http.so (ID: 00)
Nov 21 01:27:25 cam MJPG-streamer [3130]: serving client: 127.0.0.1:43976
Nov 21 01:27:52 cam MJPG-streamer [3130]: serving client: 127.0.0.1:43977
Nov 21 01:28:11 cam MJPG-streamer [3130]: serving client: 127.0.0.1:43978

To test the stream, I used such a command:
wget http://localhost:8080/?action=stream
Here is the result:

Code: Select all

--2008-11-21 01:29:00--  http://localhost:8080/?action=stream
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [multipart/x-mixed-replace]
Saving to: `index.html?action=stream.1'

    [                                      <=>                                              ] 22          --.-K/s           

And, the only 22 macic bytes that get recorded, are: --boundarydonotcross. There will be no image ever.

Can anybody hint me where to seek for the solution?! Could E3500 have some controversial or undocumented format that mjpg_streamer is unable to receive?

Disclaimer: honestly saying, why I am writing such a long problem description here is because Google seems to index zoneminder articles extremely well Could somebody more knowledgeable see it....

[xyz]

The known fact for UVC cameras seems to be that better resolutions will dictate MJPG mode.

I managed to cite the "known fact": slbpatrol discussed it at Sun Sep 16, 2007 11:55 am at http://www.zoneminder.com/forums/viewtopic.php?t=10334 . He actually advises the problem could be related to the "mjpeg to rgb24 conversion".

A year later - any new clue about the issue?

[xyz]

Seems like the monologue

Well, spent some hours and the reason for 22 bytes reply is very simple.
The uvcvideo kernel module (Debian 2.6.26-1) will never allow you switching back from YUV to MJPEG. So the right restoration sequence after you once used 176x144 YUV mode is:

Code: Select all

killall mjpg_streamer
modprobe -r uvcvideo
modprobe uvcvideo
mjpg_streamer  -i "input_uvc.so -r 640x480 -f 1 -n -d /dev/video0" -o "output_http.so -p 8080" -b 

After that it becomes possible to wget http://localhost:8080/?action=stream or to use ffmpeg for the purpose and save the actual stream into a file. So far so good.

[xyz]

And now the end of the monologue. Of course, and as usually, the issue was not camera related but was located somewhere between the monitor and the chair.

E3500 camera works absolutely well, it's MJPG also being extremely compatible. E3500 actually supports either 320x240 or 640x480. Meanwhile 352x288 is not supported by the camera. Honestly saying, it was much more confident to hunt problems after somebody sent a snapshot confirming this type of camera is indeed capable for doing 640x480. BTW, 960x720 is not OK to mjpg_streamer, it falls back to 640x480.

I already told about the impossibility to directly switch from 176x144 YUV to 640x480 MJPG. However, the main issue probably was my slow test machine (800M Celeron with 320M of mem). After changing the configuration (e.g. from 1 FPS to 2 FPS, or making restart), it could take 25-30 seconds while the Web front-end will update itself properly. During this it seems to the observer as of the snapshot is black or missing. If you are a fast decisionmaker - expect trouble . Things "started" working right after I configured 320x240 mode. Because now I knew it MUST work, I restarted ZM and began to stare at the machine. Long it took but there it appeared.

The second issue was a standard one - the configured shared memory was ok for 320x240 but not any more for 640x480. However this was much easier to spot.

The pictures (as recorded via E3500 and by ZM):

Here is where Freddie lives


Some random corner in my lab


What else I have to say is that compared to cheaper cameras, it is a hell of sensitive, the automatic white balance is OK and colors are crisp. Quite enough for 29 EUR. There is no low-light brown moodle-woodle usually created by cheap cameras.

My 1596.16 BogoMIPS machine is able to "modect" 640x480 with 3 FPS, but the lag is quite felt. 5 FPS probably is too much.