Server side push

JimNoble · Post by **JimNoble** » Tue Jan 31, 2006 11:28 pm

Is there any way to capture images from a stream that uses server side push? (Which AIUI is a netscape only thing?)

Jim

jameswilson · Post by **jameswilson** » Wed Feb 01, 2006 9:13 am

are you trying to 'push' images into zm?
As far as i know no but im sure there a work around. ZM needs to acces the files itself when it wants to. If you could getsomething on the linux box to accept the push and make a stream itself the zm could connect to it. Be careful if you try to capture jpgs from the push as you will get filesharing issues if zm and the app you find access the images at the same time.

JimNoble · Post by **JimNoble** » Wed Feb 01, 2006 9:22 am

I have a network video server (MV1000) that can provide a server side push "video" stream of jpegs.

It does still images too, but it's based on very slow and flakey hardware and drops images left right and centre. If I can get zoneminder to issue a single http request, and then feed off the streamed version, it should prove more reliable...

Jim

jameswilson · Post by **jameswilson** » Wed Feb 01, 2006 9:25 am

oh i see i think this is called m-jpeg isnt it. Can you get this 'stream' to work in firefox, ie do you know the path required?

JimNoble · Post by **JimNoble** » Wed Feb 01, 2006 9:44 am

Yep, it streams fine in firefox.

It even works of a fashion in zoneminder, but I suspect it's just using the first image in the stream and then http-requesting it again.

That seems to put an even greater strain on the video server.

Jim

candlerb · Post by **candlerb** » Thu Feb 02, 2006 8:48 pm

zm can capture a motion jpeg stream just fine. I'm doing it here - although the mjpeg stream source is another zm installation, rather than an IP camera. It should be the same.

There was a bug in 1.21.4, when built without PCRE, which caused the HTTP connection to be repeatedly dropped and remade after each frame. There's a tiny patch which fixes this, see http://www.zoneminder.com/forums/viewtopic.php?t=5549

If you're using 1.22.0 then the patch should be in there, in which case I don't know what the problem is. You could try turning on extra logging at level 6 which will show zm parsing the HTTP response and MIME headers, to see what's going on.

Regards, Brian.

JimNoble · Post by **JimNoble** » Thu Feb 02, 2006 8:57 pm

I don't know if it is definitely m-jpeg.

If it is, how does zm know to treat it as such?

Jim

candlerb · Post by **candlerb** » Thu Feb 02, 2006 9:32 pm

By means of

Code: Select all

Content-Type: multipart/x-mixed-replace; boundary=some-character-sequence

Each image is then demarked by

Code: Select all

--some-character-sequence
Content-Type: image/jpeg
Content-Length: nnn

You should be able to see this in a streaming sequence using tcpdump, e.g.

Code: Select all

# tcpdump -i eth0 -n -s1500 -X host x.x.x.x

where x.x.x.x is the webcam's IP address, while you're viewing the stream in Firefox.

JimNoble · Post by **JimNoble** » Thu Feb 02, 2006 10:24 pm

Yep, that matches exactly. However, if I change the path in the remote source setting from still to server-push image, and tcpdump again, I see a succession of http GETs of the push image.

I am running 1.22 btw.

(Cheers - always wondered how to use tcpdump

)

Jim

JimNoble · Post by **JimNoble** » Thu Feb 02, 2006 10:43 pm

I tried turning debugging on, but could see anything relevant to hhtp request parsing in /var/log/zm/* or /tmp/zm_debug.*, even at Level 9...

Cheers for the help!

Jim

jameswilson · Post by **jameswilson** » Fri Feb 03, 2006 1:25 am

it might be an idea to post your path you used to get a mjpeg image in firefox and i should be able to convert that too a zm path. Also let me know the previus settings you tried just in case i make the same mistake!

candlerb · Post by **candlerb** » Fri Feb 03, 2006 9:00 am

JimNoble wrote:if I change the path in the remote source setting from still to server-push image, and tcpdump again, I see a succession of http GETs of the push image.

Can you extract the output from tcpdump and show exactly what zm is sending to the camera, and what the camera's response is? (Just the headers of course, snip the binary JPEG data)

tcpdump -X is not a particularly convenient format for this, as you end up manually trimming off the hex part and the first 40 bytes of each packet (the IP and TCP headers). Try replacing -X with -A. You'll still have to trim off the IP/TCP headers by eye.

As for debugging: I went into Options - Tools and selected

Code: Select all

ZM_EXTRA_DEBUG          Whether to switch additional debugging on          [X]
ZM_EXTRA_DEBUG_TARGET   What components should have extra debug enabled    [_zmc_m3]
ZM_EXTRA_DEBUG_LEVEL    What level of extra debug should be enabled        [7]
ZM_EXTRA_DEBUG_LOG      Where extra debug is output to                     [/tmp/zm_debug.log+]

(note: this is for a camera whose ID is 3. Use _zmc_m1 if you have only one camera and it displays as ID 1 in the main listing. Don't forget the underscores!)

Then I did "service zm stop" and "service zm start". This creates /tmp/zm_debug.log.<pid> containing entries like

Code: Select all

01/25/06 14:10:29.452562 zmc_m3[25094].DB1-zm_monitor.cpp/1309 [Loaded monitor 3 (ground-floor), 1 zones]
01/25/06 14:10:29.452793 zmc_m3[25094].INF-zmc.cpp/190 [Starting Capture]
01/25/06 14:10:29.462456 zmc_m3[25094].DB3-zm_remote_camera.cpp/154 [Connected t o host, socket = 7]
01/25/06 14:10:29.463047 zmc_m3[25094].DB3-zm_remote_camera.cpp/174 [Request sent]
01/25/06 14:10:29.463372 zmc_m3[25094].WAR-zm_remote_camera.cpp/514 [Unable to use netcam regexps as not compiled with libpcre]
01/25/06 14:10:29.513213 zmc_m3[25094].DB3-zm_remote_camera.cpp/219 [Expecting 57 bytes]
01/25/06 14:10:29.513656 zmc_m3[25094].DB3-zm_remote_camera.cpp/244 [Read 57 bytes]
01/25/06 14:10:29.513907 zmc_m3[25094].DB6-zm_remote_camera.cpp/624 [HTTP/1.0 200 OK
Server: ZoneMinder Video Server/1.21.4
]
01/25/06 14:10:29.514142 zmc_m3[25094].DB6-zm_remote_camera.cpp/632 [Got http header 'HTTP/1.0 200 OK
Server: ZoneMinder Video Server/1.21.4
']

Following more of this shows all the HTTP headers being captured and parsed.

After a few seconds, uncheck ZM_EXTRA_DEBUG and then stop and start zm again. Otherwise the log files get very big very quickly.

HTH, Brian.

JimNoble · Post by **JimNoble** » Fri Feb 03, 2006 9:27 am

Cool, ta. I'll give it a go tonight.

Jim

JimNoble · Post by **JimNoble** » Fri Feb 03, 2006 8:47 pm

I've tcpdumped the fetch from zoneminder, and from safari (seems to support server push like firefox does).

From safari:

GET /user/ppush1.jpg HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8
Authorization: Basic bXYtdXNlcjp3aWJibGU=
Connection: keep-alive
Host: xxx.xxx.xxx.xxx
HTTP/1.0 200 OK
Server: Active Imaging Mv-NET PLUS 2.10
Expires: 0
Pragma: no-cache
Content-Type: multipart/x-mixed-replace;boundary=ThisRandomString
Content-Type: image/jpeg
Content-Length: 14557
blah blah JFIF...

But from zoneminder:

GET /user/ppush1.jpg HTTP/1.1
User-Agent: ZoneMinder/1.22.0
Host: xxx.xxx.xxx.xxx
Connection: Keep-Alive
Authorization: Basic bXYtdXNlcjp3aWJibGU=
HTTP/1.0 200 OK
Server: Active Imaging Mv-NET PLUS 2.10
Expires: 0
Pragma: no-cache
Content-Type: image/jpeg
Content-Length: 14435
blah blah JFIF.

I guess the MV1000 is deciding not to provide M-JPEG based on the "Accept" and/or "User-Agent" stuff. I'm doubting it's the latter, as I don't think the MV1000 would be aware of Safari's server push capability...

Can/should zoneminder do the "Accept" bit...? Or is it the MV1000's response/assumption the problem?

Jim

candlerb · Post by **candlerb** » Sat Feb 04, 2006 9:16 am

JimNoble wrote:I guess the MV1000 is deciding not to provide M-JPEG based on the "Accept" and/or "User-Agent" stuff. I'm doubting it's the latter, as I don't think the MV1000 would be aware of Safari's server push capability...

I guess the camera is just by checking for 'Mozilla' in the User-Agent string, although that's a flawed test. Many versions of Internet Explorer announce themselves as "Mozilla (compatible; MSIE...)" for historical reasons. You could easily change ZoneMinder to send

User-Agent: Mozilla/5.0 (ZoneMinder/1.22.0)

and if that's the problem, I'd say it's a reasonable thing to incorporate. Just grep for "User-Agent" in the source code.

You can test your theories by manually issuing the HTTP request. Simply "telnet x.x.x.x 80", issue the GET ... line and the HTTP request headers, and end with a blank line. Note that the first line is case-sensitive. Then repeat with different User-Agent, different Accept etc.

JimNoble wrote:Can/should zoneminder do the "Accept" bit...? Or is it the MV1000's response/assumption the problem?

Since motion JPEG over HTTP is not standardised anywhere, it's hard to say which side is at fault. Personally I think the camera should have offered two URLs, one for a static JPEG and one for a motion JPEG, so the client could explicitly choose one or the other.

Regards, Brian.