Get all access to the world's best video surveillance information.

MJPEG vs. H.264

by John Honovich, IPVM posted on Apr 17, 2009 About John Contact John

Recently, IQinVision releaed an article advocating benefits of MJPEG.

[Update Dec 2010: We conducted extensive testing comparing MJPEG and H.264. Read our Test Results of MJPEG vs H.264.]

While I found the article technically accurate, well written and worth reading, the nature of the application and its economics demand that MJPEG be almost always avoided. Since H.264 is hot right now, this is a popular claim to make. However, a discussion of this can help examine the economics and operational drivers driving this interest.

Jason's central claims are:

1. With moving cameras or images of high activity areas, MPEG4 and H.264 provide little bandwidth savings relative to MJPEG.

2. Proper network design requires factoring in worse case scenarios so you will need to dedicate the same amount of bandwidth whether or not you use MJPEG, MPEG4 or H.264.

3. MJPEG provides higher quality because of no intra-frame compression.

4. Unlike MJPEG, with MPEG-4 vendors deviate from standards, increasing potential integation costs.

My counterpoints are:

1. For most users, cameras usually have low or modest activity, translating into significant savings for MPEG-4 or H.264. Most cameras in the world are fixed. Most cameras have significant periods during the day when there is little or no motion (nights, weekends, etc.) Even within PTZs, PTZs are often left at a home position, or iterate over a series of pre-sets stopping for 5 - 10 seconds each.

2. Many, perhaps most organizations, do not set network bandwidth budgets for worst case scenarios. Sometimes, organizations don't want to pay the money for the extra capacity but sometimes it can't be done due to constraints of reutilizing existing infrastructure (very common in wireless networks). In other words, organizations generally trade-off infrequent pixelization for immediate cost savings. Maybe this is 'objectively' wrong but this is common.

2a. Jason does not discuss storage but storage is a HUGE economic driver in the move away from MJPEG. I have had a number of occasions where my DVR/NVR with a 1TB hard drive was only recording for 13 days. Why? I had forgot we recently integrated just a few megapixel cameras using MJPEG. Let's say we can save 1 Mb/s by switching from MJPEG to MPEG4. Over a two month period, for one camera, that is 650 GBs. It would cost you $300 to $600 to add that much storage for each MJPEG camera.

3. As for quality, the difference in quality is usually close enough that most customers are ok with it, especially for the savings.

4. The issue with deviation from standards is generally a one-time cost/problem that can be amortized by the manufacturer over many different customers. In the larger scheme of things, it's mainly a nuisance.

In sum, then, the economics of reducing network and storage costs are usually very significant budgetary and operational factors that drive purchasing decisions. With megapixel manufacturers starting to announce H.264 support, it will be interesting to see what IQinVision does.

Comment #1 by Jason Spielfogel posted on Apr 20, 2008
First, I’d like to thank John for taking the time to read my original article and to give very well thought out commentary and counter-claims. I have attempted to do the same, and here is my response to John’s continuation of my original article on MJPEG compression: <br /> <br />1. John’s first counterclaim is that in most applications cameras have low or modest activity, translating into significant savings when using MPEG-4 and H.264 compression. This of course depends on the application (an airport or 24-hour convenience store is very different than a bank when it comes to percentage of significant activity in a 24 hour period), but generally I would agree with John. However, I also believe John’s statement does not take into account selective streaming. What I mean is, in the days of analog cameras, the camera is always on; always streaming; always 30 FPS. In the IP camera world this is no longer an absolute, and features like on-camera motion detection, scheduling and dynamic compression can make it so that end-users can control their bandwidth regardless of the compression scheme for their application. So, in that bank where nobody SHOULD be in the branch at night, the camera can be set to transmit at high compression and perhaps 1 frame per second (or not at all) until motion or alarm activity occurs, at which point the camera could be instructed to send higher resolution and frame rate images. I would argue that this advantage of IP cameras can completely negate the savings enjoyed by MPEG-4 and H.264 in applications where there are significant periods of low activity. Since the vast majority of Network Video Recorders (NVRs) on the market today also support this feature, it’s a very simple integration to set it up. <br /> <br />2. John’s second counterclaim is that most organizations don’t plan for, and won’t pay for, infrastructure to support “worst case scenarios.” To this point I would whole-heartedly agree. I would also put forward that the perception in the market today is that MPEG-4 and H.264 is a panacea solution that solves everyone’s bandwidth and storage concerns. I think our first responsibility is to make it very clear that there is no panacea solution. In fact this article is part of an effort to dispel the myths surrounding MPEG-4 and H.264 compression so that they are not viewed as a “one size fits all” solution and to encourage integrators and end-users alike to think about each installation independently and then choose a compression scheme that best fits the application. The tradeoffs for each compression type should be well-understood and planned for. For example, the fact that MPEG-4 and H.264 don’t give as good of image quality in high motion, and the fact that MPEG-4 is only designed for sub-megapixel resolutions and below. Also, while H.264 may require less bandwidth and storage space than MJPEG, it requires much greater decompression CPU capability then either MPEG-4 or MJPEG. Once you talk about double digit channels of multi-megapixel H.264 being simultaneously decompressed, you quickly run into a wall that can only be solved by using multiple PIXAR type machines to handle this decompression. This also represents a significant budgetary challenge, and must be considered. John’s “2a” counterclaim is that I didn’t discuss the cost of storage. He’s right, I didn’t, but I would respond to that counterclaim by saying the cost per gigabyte of storage is half of what it was 18 months ago, and will likely halve again under Moore’s law in the next 18 months. I believe if the relative cost per gigabyte relative to the increased file size of newer high-definition surveillance cameras is examined, they would be found to be roughly equal. <br /> <br />3. John’s third counterclaim is that the quality difference between MJPEG, MPEG-4 and H.264 is close enough that most customers are okay with it. This is the only counterclaim that John puts forward that I find to be incredible and completely untrue in my experience. First, MPEG-4 isn’t even designed to handle resolutions over D1 (752x480 pixels). I’ve seen implementations of MPEG-4 all the way up to 1.3 Megapixel (1280x1024 pixels) but that’s a big stretch. There certainly aren’t applications for MPEG-4 above 1.3 megapixel, while there are cameras above 1.3 megapixel – all the way up to 5 megapixel through IQinVision, and even up to 16 megapixel through one other manufacturer. H.264’s standard does allow for multi-megapixel compression, but not in any camera that are shipping today, and the decompression challenge relating to H.264 mentioned in the previous counterclaim cannot be ignored. Also, MPEG-4 and H.264 just aren’t as good in high motion as MJPEG. MPEG-4 and H.264 both produce artifacts and are both less efficient in times of high activity….it’s just reality. IQinVision’s customers have seen this difference, enough so that it has driven a very successful MJPEG-based camera business for IQinVision and other manufacturers. There are other technical concerns as well. H.264 for example requires more power to the camera and generates more heat on the camera. In applications where the camera is particularly sensitive to environmental conditions (Phoenix, Arizona in Summer, for example), that extra heat produced by a camera streaming H.264 could be enough to push the camera out of spec or add additional noise to the signal. Noise and H.264 are a bad combination because it creates more artifacts and significantly decreases the efficiency of H.264. Low-light is a similar consideration because low-light equals lower signal-to-noise ration equals more noise, equals less efficient compression. MJPEG’s compression is not nearly as impacted by higher signal-to-noise ratios when compared to MPEG-4 and H.264. <br /> <br />4. John’s fourth counterclaim is that the issue of deviating from standards is generally only a one-time pain that can be overcome relatively easily. He’s basically correct, except that future-proofing a system must be considered. For example, if an infrastructure is set up on MJPEG, then as it is expanded is suddenly changed to H.264, things such as decompression CPU cycle bandwidth must be considered as it may require a completely new, and much more expensive, server and client architecture, to support. This significant additional cost cannot be amortized by the manufacturer; it is solely borne by the end-user. <br /> <br />In closing, John gives some very real market scenarios that demonstrate the reality of today’s perceptions and installation reasoning for IP camera systems. I hope that my counterpoints properly redress his. I would emphasize again that this is no one perfect compression scheme for IP surveillance. Multiple factors of budget, expected image quality, predicted motion throughout the day and a host of other application-specific criterion should be considered before choosing a compression type that best fits the needs of the end-user. Currently, IQinVision has standardized around MJPEG compression, but we are always researching more emerging technologies and will build those into our product roadmap as is appropriate and as is dictated by the market. <br />

Comment #2 by John Honovich posted on Apr 20, 2008
Thanks, Jason. Your analysis is great and the depth of it really helps to illuminate key challenges. <br /> <br />Jason demonstrates two fundamental elements where I am either wrong or grossly misleading: <br /> <br />1. Designing for Standard Definition (SD) cameras is significantly different than High Definition (HD) cameras. I unfairly munged both categories in one discussion. While I think the case is clear for standard definition cameras that MJPEG should be avoided, as Jason rightfully demonstrates, it is not so easy to claim that for HD or megapixel cameras. <br /> <br />2. MJPEG is the current de facto standard for megapixel cameras. Though H.264 is suddenly the hot term in the industry, H.264 for megapixel cameras is just at its very beginning. IQinVision's use of MJPEG is totally in line with best practices in this market segment. As Jason clearly discusses, there are a number of serious constraints on using H.264 for megapixel cameras in the real world. <br /> <br />Advocating using a codec other than MJPEG for megapixel cameras is somewhat unfair as it amounts to arguing for something that does not exist over something that does exist. That being said, megapixel camera companies are starting to announce support for H.264 (e.g., Lumenera). To Jason's point, it's only a 1.3 megapixel camera and I don't know the impact in video quality, reliability or cost. However, this will make the MJPEG - H.264 megapixel discussion more pressing. <br /> <br />So if am advocating to avoid MJPEG (for most applications) and most, if not all megapixel cameras use MJPEG, what does that mean? <br /> <br />The economics of megapixel cameras makes it still difficult to justify for mainstream use (mainstream admittedly being a vague term). <br /> <br />Let me explore this point briefly by responding to Jason's discussion. <br /> <br /> <br />Using a more 'efficient' CODEC like H.264 vs MJPEG still saves significant bandwidth and storage even if you employ on camera motion detection, scheduling and dynamic compression for 2 practical reasons: <br /> <br />1. Many customers are reluctant to depend on computers to decide what to record or not record. The fear is "what if the camera, NVR, or DVR makes a mistake and misses a key event?" Very frequently, customers decide to be conservative on using these features. <br /> <br />2. Most motion detection systems are unreliable in detecting motion. Because of that, most manufacturers set defaults low to make sure it does not miss a valid event. You end up with numerous nuisance motion events that can chew up an additional 20% to 50% more storage/bandwidth. (You can make them very reliable but then you are increasing the cost of the camera and sophistication of the analytic you are using). <br /> <br />I agree with Jason that you should use these features but that the additional storage/bandwidth will still be significant. <br /> <br />Finally, while I agree with Jason that storage prices continue to fall, that does not address the present financial concerns of purchasers. If it costs me $500 more per camera for storage today, it does me little good to know that 18 months from now, it will be $250. <br /> <br />That being said, it is certainly a good sign for future market acceptance. <br /> <br /> <br />In closing, while I believe strongly that MJPEG has real costs that hinder the acceptance of megapixel cameras, I agree with Jason that H.264 has its own real world problems today. When, how and if H.264 for megapixel cameras will mature enough to be a better choice for megpaixel cameras seems to be a key question for the future of the megapixel market. <br /> <br />Best, <br /> <br />John <br />

Most Recent Industry Reports

Testing Axis' Top Low Light Camera Q1635 on Nov 23, 2015
Low light performance continues to improve, first driven by advances in image processing and now increasing number of 1/2" imagers in 1080p HD cameras. IPVM has recently tested new super low light...

Audio Analytics Aggression Tested on Nov 20, 2015
What if you could use your IP cameras to detect fights before they start?&nbsp; That is the goal of Louroe / Sound Intelligence with their recently released Aggression Detector audio analytics. Cl...

Pelco Optera 12MP Multi-Imager Tested on Nov 09, 2015
This summer, Pelco came out firing against Arecont, touting the superior performance of its new multi-imager line vs Arecont's. But is this really the case? We bought a Pelco Optera 180&deg; multi...

IP Camera Bootup Shootout 2015 on Nov 04, 2015
IP cameras, like PCs, take some time to boot up. And just like PCs, the amount of time can vary greatly. Many people do not care but some people find it annoying. Perhaps more importantly, in surve...

Live From China on Nov 02, 2015
China's growing influence, if not dominance, of the global video surveillance market is unquestionable. To better understand this, IPVM has gone to China. Our first stop is CPSE, which claims ~100...

Network Cabling for Video Surveillance Guide on Oct 30, 2015
In this 14 page guide, we teach the fundamentals of network cabling for video surveillance networks, how they should be installed, and the differences in testing them for production networks. Spec...

Large Video Surveillance Systems Guide on Oct 29, 2015
This 14&nbsp;page guide explains the key uses, design factors, and players in the large system&nbsp;surveillance market. A global group of 80 integrators&nbsp;responded,&nbsp;each offering insig...

Sony 20MP / 4K Camera Tested on Oct 26, 2015
For 18 month, Sony has been hyping 4K cameras, a year before they even announced a 4K network camera. Now, amidst intense&nbsp;competition and price pressure, Sony has released their long awaited 2...

ONVIF Screen Capture Tested on Oct 23, 2015
Recording a PC's screen to a VMS has several uses, but historically has required&nbsp;expensive dedicated encoders or specialized software for each VMS. Now, a new offering called Screen ONVIF has...

Milestone Arcus VMS Tested on Oct 21, 2015
For more than a decade, Milestone was a Windows only VMS. With the Internet&nbsp;shifting power away from Windows OSes, Milestone launched a new VMS, called Arcus, which can be embedded onto Linux ...