BUG: Netcam code cannot handle Allnet 2201 Motion Jpeg

Hi,

I believe the MJPEG stream of the Allnet 2201 Ethernet Camera is strange enough to be not recognizable to the netcam code of motion 3.2.7. (It seems it does set Content-type: application/octet-stream, etc)

The mjpegsnif dump below does not contain the string "TOSHIBA", so it is probably not a toshiba cam.

http://www.lavrsen.dk/twiki/pub/Motion/NetcamMjpegStreamDumps/AllnetALL2201.mjpegsnif

Environment

Motion version:	3.2.7
ffmpeg version:
Shared libraries:	-
Server OS:	debian GNU/linux, kernel 2.6.11.10

-- HerwigWittmann - 15 Feb 2007

Follow up

Hi Herwig,

I hope I'm not jumping in front of anyone here (Kenneth or Angel) but I have been looking at netcams recently.

Motion doesn't support 'real MJPEG' cameras, only the MJPEG type which is multipart Jpeg, which is subtly different. Your sniff file begins with:

HTTP/1.1 200 OK
Server:  boa/0.94.13
Expires: Mon, 06 Jan 1990 00:00:01 GMT
Content-type: application/octet-stream
Connection: close

MJPG

Looking round on the internet it might be Mpeg4, which Motion can't handle (right now).

If anyone understands how to decode a Mpeg-4 byte stream, perhaps they could help out, and we can patch Motion to read it.

Looking past the 'MJPG' string in your sniff file, at 0x030 bytes from the 'M' of MJPEG there is an 0xFF 0xD8 which signifies a Jpeg, and at 0x036 bytes (from the 'M' of MJPEG) there is the string JFIF. This looks like the beginning of a Jpeg image, which Motion does understand, and there are more strings like that later in your dump. So perhaps something can be done.... we only need to work out the length of each image and work on a patch.

In the short term you could look for a URL of your camera which returns a Jpeg image. It will be slower but functional. The URL may be:

<ip-address>/image.jpg

or similar. I appreciate this may be difficult to find, and looking at the WorkingDevices page may give you some ideas for URLs to try. (I once did a 'strings' on the binary of a camera firmware to find out what URLs to use....)

-- SimonW - 15 Feb 2007

I did some more work on this. I used a program called JPEG Extractor on your sniff file. The results were this:

So there are JPEG files in your sniff file, 3 of them in fact - all pretty much identical (frames of video). I've done about all I can for now, perhaps someone else will chime in...!

-- SimonW - 15 Feb 2007

Hi Simon, thanks for having a go

I believe the Camera can deliver either MPEG-4 over RTSP, or some strange kind of MJPEG over HTTP. The URL for obtaining single jpeg images is documented in the manual, but it takes 5 seconds from HTTP GET request until the image is delivered, which makes this method too slow for surveillance.

In addition, when viewing the the motion Jpeg(?) stream with firefox, a few rows to the bottom of the image keep flickering. I think this may be the same artefact visible in the image you generated with JPEG Extractor, so maybe this cam is broken beyond repair :/

Too bad, it seems to be the cheapest PoE netcam on the market: http://geizhals.at/eu/?cat=camsec&sort=p

-- HerwigWittmann - 15 Feb 2007

Hi again Herwig,

Hmmm, perhaps that's what the sniff file is, Mpeg4 over RTSP. I found that RTSP has a port number 554 registered for it, and 8554 as an alternate port. Could you do a sniff of port 554? You will have to edit & recompile mjpegsnif.c to do that. Even having a look with telnet to port 554 might show something up.

You may choose to return your camera if you purchased it retail, using the corrupted picture as evidence of a fault.... and choose another model, perhaps. But it would be worth capturing some RTSP data beforehand if possible

Simon. -- SimonW - 15 Feb 2007

Simon, I think I compiled mjpegsniff to use HTTP, and it should be GETting the URL that the manual claims to be for MJPEG, it even ends in mjpeg.cgi - but thats only documentation claims

Best regards, -- HerwigWittmann - 15 Feb 2007

OK. So to read that MJPEG stream we will need to patch Motion, since it is not a Content-type that we recognise, and those bytes of unknown function before the 0xFF 0xD8 need to be stripped out to find the Jpeg image. There also might be difficulty with recognising the length, since it is not given in the headers, although Motion is able to read images without knowing the length.

-- SimonW - 16 Feb 2007

Just noting this parallel Wiki topic: FeatureRequest2007x02x12x195322

Perhaps the topics could be combined.

-- SimonW - 19 Feb 2007

Yes , that is not a bug report is a FeatureRequest.

Anyway i don't think is just an not recognised Content-Type, because MJPEG ( Motion JPEG ) is not a complete JPEG image but a JPEG without huffman table.

-- AngelCarpintero - 19 Feb 2007

Fix record