Subscriber Discussion
When To Use MJPEG Vs H.264?
Many MP camera manufacturers allow for the selection of multiple compression technologies. Typically, there is at least one selection for Intra-frame compression (MJPEG) and one selection for Inter-frame compression(MPEG-4, H.264).
Does anyone have specific application examples where one compression technology may be chose over the other? I understand bandwidth and storage could be factors driving that decision, but I was thinking factors such as lighting conditions, scene activity, detail, etc....
Thanks,
Eric S.
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.
The other major benefit for server side analytic software is that MJPEG requires less computing resources than H.264 to convert to bitmaps to perform the analysis.
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.
I recall this being an Avigilon claim about JPEG2000 that they were really high on until they started discontinuing their JPEG2000 lines and going to H.264 like everyone else.
We've tested MJPEG vs H.264 in the past and did not see material differences in the professional cameras we tested in.
It's possible that's where I remember reading it, in Avigilon marketing material. In full disclosure, I am employed by an integrator which is an Avigilon partner. I too found it interesting that they discontinued JPEG2000 products...
Eric, here's a reference from Avigilon's Understanding Compression Technologies marketing piece:
"Two additional features of JPEG2000 compression are its ability to capture a wide dynamic range and its ability to scale to higher resolutions. Dynamic range is an important topic in surveillance because many cameras are challenged to record bright and dark areas that vary dramatically throughout the day and by season. The ability to capture dynamic range is expressed in bits. Most compression technologies capture 8-bits of dynamic range, which means it can describe 256 different intensities of light within the image. The sensors used in surveillance cameras are often capable of capturing more than 256 intensities of light and more information than even the human eye can see. JPEG2000 was designed to preserve the extra information that the sensors generate and maintain it in the compressed video. "
Thanks John! That's it! I would have spent the rest of the day trying to remember where I read this.
I guess it's kind of a moot point now , since they moved away from that compression technology.
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.
"A Client application viewing a MJPEG based video will have a lot less work to do compared to its H264 counterpart."
I've noticed that when toggling an IP camera web client from a MJPEG to an H.264 stream on a PC, that the MJPEG stream requires more CPU. Anyone care to repeat that and share results?
H264 encoder/decoder for such would consume more processing power than MJPEG. However, many of these codes are now complete HW ips or some DSP based relying partially on specific HW accelerators. This reduces the load on the CPU itself for encode/decode
On the other side, H264 Vs MJPEG bitrate could easily be a factor of 5. Transmitting such high bitrate consumes CPU bandwdith as well.
John,
Can you say which camera(s) [or vendor series] did this so I can see if I have one in my lab? My observatons are with the VMS based client applications and not the camera's own web interface. I will observe this as I work with the cams I have to see if the camera web viewer has different performance metrics.
John, my experience is the reverse. Client PCs CPU requires more CPU when running H.264 than MJPEG. I use a rule of 2 to 4 cameras per CPU core as a base and adjust from there.
Also, if we have a PTZ camera that is on a tour (constantly panning/tilting etc.) Mjpeg takes less bandwidth and CPU power as the pixels are constantly changing changing.
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.
Newest Discussions
| Discussion | Posts | Latest |
|---|---|---|
|
Started by
David Little
|
5
|
less than a minute by David Little |
|
Started by
John Honovich
|
12
|
less than a minute by Undisclosed Manufacturer #5 |
|
Started by
Brian Rhodes
|
1
|
less than a minute by Brian Rhodes |
|
Started by
Undisclosed Manufacturer #1
|
8
|
26 minutes by Undisclosed Manufacturer #1 |
|
Started by
Undisclosed Integrator #1
|
2
|
less than a minute by Sean Patton |
