mpeg vs jpeg vs ftp?

[bs27975]

My camera (Trendnet TV-IP751WIC) will stream either via /video/mjpg.cgi or via /image/jpeg.cgi.

Could someone point me towards links as to why one would chose one or the other? (Been using mjpg, been happy, but with other browsing / event playback issues I have, I now wonder.)

-----

I get a monitor being red = unhappy, orange = happy. (There's no green, here, right?) I thought the same true of Function - I always thought orange was where one wanted to be. I see Modect in green recently (thought it used to be orange), and get that that means all is well (green). I thought orange meant all was well (too).

I thought I saw in the wiki that green means zm knows the camera itself can do motion detection and is taking advantage of it.

I also seem to remember seeing green simply means alarms are also activated. (Don't know / remember how / when I did that, but it seems a good thing - seem to see a higher frame rate in the monitor window, and nicely see alarm in colour when something is going on.) I leave the monitor window up on another computer.

Having alarms turned on is a good thing? (I'm just looking for motion to get recorded. Nothing special beyond that has occurred to me as being useful. Not looking for e-mail or other magic / devices to be triggered.) [Perhaps alarms / green happened as a result of checking raise window upon event?] As far as I knew I was happy when Function was orange, too. Just don't remember seeing alarms - not sure I care, either. The camera is just watching out my front door -this isn't a live monitored / security station.

It separately seemed to me that green = using camera's motion detection can't be right - how would it know / manufacturers would be shifting the sands under zm's feet constantly.

The camera will do motion detection, but only puts such out to ftp or e-mail. I've always felt something like zm will have way more smarts and horsepower for motion detection / analysis / doing useful things than any wee little camera. Is there any advantage to camera motion detect via ftp, then having zm chew on things from there? I don't believe the camera's motion detection has a hope of having the same sophistication zm would have.

I'm not worried about load, at this point, it's an i7-2600k - intel quad-core with hyperthreading. If I can overload that with one or a few cameras, I'm in a different Kansas!

Sorry is this is convoluted. Just sinking into this stuff, and terminology / confusion is rampant.

Thanks for any good links to finite / concise references / explanations.

[mikb]

either via /video/mjpg.cgi or via /image/jpeg.cgi.

Could someone point me towards links as to why one would chose one or the other?

In my opinion: MJPEG should be more efficient. Although both streams are likely to be similar quality, on my DLink DCS900 cameras, MJPEG is kicked off with a single HTTP request, which causes an endless stream of JPEGS to be pushed by the camera. However, JPEG pushes one picture only. So you have to HTTP Request each picture individually, more overhead, basically pulling pictures.

The camera will do motion detection, but only puts such out to ftp or e-mail.

Unless you need that, separately from Zoneminder, just ignore it and switch it off. Zoneminder will run rings around the built in modetect ...

Is there any advantage to camera motion detect via ftp, then having zm chew on things from there?

Not really ... Cons :-

You'd only ever get clips that had motion in them ALREADY. If the camera decided there was no motion, ZM would have nothing to chew on

If there's motion seen by the camera, then there's motion, so why ask ZM to double check?

An extra layer of things to go wrong, how will ZM know if the camera is producing no clips because of no motion, or because it's died? If ZM was talking to the camera, it would know things were amiss.

Pros :-

No network activity unless there's motion. Saves wearing out your network transferring endless pictures of "nothing" for ZM to analyse.

Takes the load off ZM server if it's already stressed. Sounds like you're not worried on that one!

[bs27975]

Thanks for the thinking out / through.

In my opinion: MJPEG should be more efficient. ...

Hadn't considered the overhead of the additional http requests. Good point.

... on my DLink DCS900 cameras ...

Hmmm. Considering a DCS-930L - guess one never knows one cameras is not enough until after sinking into the ecosystem. (Becomes debatable whether to spend more than twice as much for a wider angle / more capable camera, or a 2nd cheapie. Hmmm.)

I do note the wiki notes mjpg 'issues' (?) with the cam, though. Hmmm.

Zoneminder will run rings around the built in modetect ...

Rather expected that.

If there's motion seen by the camera, then there's motion, so why ask ZM to double check?

Guess I expected to simply set motion rather than detect (or something). Thinking through that, that makes no sense. Constant record would still record a whole lot of same, until the next 'motioned' frame sent by the camera.

Never mind.

... how will ZM know if the camera is producing no clips because of no motion, or because it's died? If ZM was talking to the camera, it would know things were amiss.

Good points, but it's not like zm can do anything about it like send the camera a reset. OTOH, if it matters, and one is watching, presumably zm would be dancing around trying to grab your attention that something's amiss. Good points.

Takes the load off ZM server if it's already stressed. Sounds like you're not worried on that one!

Or, at least not yet.

Guess what I was really thinking was not so much zm on the fly analysing the streams, so much as scanning the ftp directory and incorporating the files into the event / presentation system. Feels like there's some value in that.

Let alone, interframe analysis / outlining could still be done, integrating multiple sources into the single zm presentement. And not being 'live' (real-time) monitoring, could be done on a lower priority level.

Guess it's back to multiple ways to skin a cat. Granted, I believe in K.I.S.S., and not do ftp unless / until necessary for lack of capacity factors.

Very good insights, thank you very much for the post!

[mikb]

it's not like zm can do anything about it like send the camera a reset.

True, but at least in can tell the difference and log it, turn the status RED etc. I'm sure someone somewhere has a mod that could reset the camera remotely. If not, that should be a feature request

Actually, I use a (timed) script once a week to kick all my DCS900's as they all have some kind of internal memory leak, and after a couple of months of solid running, they start dropping TCPIP connections. ZM feverishly restarts the stream, but when you are getting more drops-per-hour, you realise something's up. At 936 drops-per-hour, it gets your attention. A remote reboot later, and all is well.

You'd need to look up the specifics for your camera, but one of these will work on DCS900 cameras for firmware v3 or v4 (they changed stuff, typical!) ... you need to hunt down the HTTP interaction for what happens when you hit the "soft reset" on the web interface!

wget --http-user=root --http-password=PASSWORD -O /dev/null --post-data="Reset= Yes " http://cam01/DoReset.HTM

wget --http-user=root --http-password=PASSWORD -O /dev/null --post-data="Reset= Restart Device " http://cam01/File.htm