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

Samsung Covert WDR Camera Tested on Oct 07, 2015
IPVM member Steve Beck asked us in IPVM chat to test the Samsung covert WDR camera (the SNB-6011) so we did it. Covert cameras are often used in ATM applications, locations with demanding dynamic ...

Axis Video Analytics Are Weak on Oct 05, 2015
For more than a decade, video analytics has frustrated and disappointed users. Now, Axis has released&nbsp;their own "series of robust video analytics applications" that they call Guard Suite. Unf...

33 New Products Directory - Fall 2015 on Sep 28, 2015
&nbsp;New products or major tech isssues&nbsp;that IPVM has reported on&nbsp;this summer / fall: Axis Releases Their Own Video Analytics Axis Non-IP Camera / DVR Kit Is Here BluB0X - The Most ...

Axis YouTube Livestreaming Camera App Tested on Sep 25, 2015
Broadcasting live video&nbsp;has historically been complex and costly, with manual setup and pricey monthly subscriptions required. Now, Camstreamer is aiming to change that, with an Axis Camera A...

Anixter/Tri-Ed Northern Video Tested on Sep 18, 2015
ADI is an IP video manufacturer now (see IPVM's ADI W Box test results). And now, their top rival, Anixter's Tri-Ed arm has also entered the IP video manufacturering business, under the&nbsp;North...

Axis Digital Autotracking Tested on Sep 16, 2015
As camera resolutions continues to climb, the likelihood that you will ever display any camera at full resolution on a monitor declines. This is even more improbable for the normal configuration of...

Access Control Book 2015 on Sep 16, 2015
This book is the textbook for our&nbsp;Access Control Course, today is the last day to get in the course. This is the best, most&nbsp;comprehensive access control training in the world, based on o...

Hikvision iVMS-4200 Tested on Sep 14, 2015
Though best known for their camera and recorders, mega Chinese manufacturer also makes their own VMS software. In this report, we share test results of Hikvision's iVMS-4200, their VMS that works ...

Google Breaks Surveillance Browser Support on Sep 09, 2015
Now you have a choice. Broken video surveillance web browser support or an insecure, prone to crashing interface. As Google has been warning for ~2 years, Chrome has now discontinued NPAPI suppor...