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 />

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 />