When To Use MJPEG Vs H.264?

For the most part environmental conditions have little to do with it. Many times you have an h.264 stream at the maximum supported resolution being recorded and used on your standard PC-clients. The MJPEG stream is often used for mobile or tablet based viewing, embedding in simple webpages and things like that.

In some cases, such as license plate capture (LPC) the MJPEG stream may have a slight edge over the h.264 stream in terms of reduced motion blur on a given frame. MJPEG also has the ability to more easily select any specific frame for extraction and analysis, such as for an LPR (license plate recognition) application.

I do agree with previous mentionned points. LPR and ALPR whith moving objects in dark envuironement especially cars but also face identification in darkness with PTZ domes might be beter with Mjpeg instead of H264. For Smartphone it's just because some brands doesn't support H264... (quicktime requires to much CPU :-)

Analytic software are working on low res (apart of ALPR), and do prefer Mjpeg because it doesn't generate as much noise as H264 in P-frames and sharpness is often better for small "few pixel" perimetral object detection or long fence crossing.

I remember reading an article [the source escapes me] that discussed compression technologies versus dynamic range.

The claim was that certain implementations of MJPEG compression were able to capture the more information with respect to the dynamic levels of light in a particular scene (dark and light areas in a room, for example).

I’d be interested in testing this theory to see if the claim was valid.

What I can see on the filed it that most integrators deploy H264 with (basic main high wo cares profiles mots don't know) with high Ips rates and good quality compression and CBR outputs that they don't control at all (most of the time provided on the manu web) , not imagining that H264 at night is .... multiplifyuing bandwith by 5, 7, 10..or more. So if CBR is optimistic based on Day profile... you get artefacts and noise generated by the camera tryiing to compress the more it can .. H264 images which an getting fat

With Mjpeg the bandwidth increase isn't such big, so quality is globaly not decreased at night.

Let me try to answer this from a Client and Server hardware performance point of view.

A Client application viewing a MJPEG based video will have a lot less work to do compared to its H264 counterpart. On the Server side, if the server is doing motion detection (vs the camera), it will need less resource for the MJPEG streams.

Many times lately when I am discussing Client performance with the VMS vendors, they recommend defining Dual streams from a camera where one is for Live viewing and is the MJPEG one, and the other is for Recording and is the H264 one.

If a VMS supports mobile/Web interfaces, my lab testing has shown that most of these will Transcode the camera streams into MJPEG from whaever form they come in from the camera, and will use a lot of resource if the source stream is H264 vs MJPEG.

If you have many web connections to support and can not do dual streaming, then you should be using a dedicated system to perform the Transcoding function instead of doing it on the recording server.

Note some software suports video card GPU processing, taking the load of the main CPU.

H.264 in all cases. MJPEG should be a fallback solution in case H.264 is not supported, but H.264 has way superiour compression (RD) performance - lowering the needs for bandwidth and storage capacity.