amirm

Maybe you have not been in communique with an ad rep from MacWorld - they actively engage potential advertisers on how they can promote third party products to the Apple community - it's a great model and creates win/win for both vendor and reader. Most of Macworld's content is about what-else-works-with-Apple. BTW that is not our mission statement, it's one of the many services we provide to vendors to enable us to fund MxInstaller magazine, so that it can be distributed to the community free of charge. What I quoted was under "About theipacademy." It said that you published your articles every so often and then what I quoted. So if it is not your mission, not sure what it is. And no, I don't agree that paying for advertising buys editorial content of Mac World. If you covered the entire industry and then showed a Mobotix ad, then you could say you are like Mac World. Your business model is the other way around where the entire editorial content is from the commercial vendor. My read of your services is that if I pay you, you will publish what seems to be independent articles but in reality are infomercials for my product. If that is not what you mean, then maybe you should clarify it there. Again, I think in the context of commercial intent, you do a reasonable job. There is useful information and as long as the person knows there is an intent there to promote that product as I mentioned, then all is well. I addressed your comments relating to the tutorial and MxPEG, for the rest of the community, because they were incorrect. What was incorrect? You agreed with everything I said. The only thing that was incorrect was your clarification saying an article that has an headline of H.264 in it, is really about how you store the bits and not the codec. The merits of their codecs is what I listed, not some twist it of it into some other talking point. BTW, on a personal level, I have been a champion of Mobotix here and elsewhere. This interchange however has really soured my positive view of the company. If they have hired you to come and post this way, and you can't tell the friend from foe, then someone is not doing their job well.

Hmmm. This is the description you provide on your Youtube web site: "We actively assist third party manufacturers of specialized software, storage, networking and wireless technologies to help them align their products with the megapixel video surveillance market. Contact us if you'd like to learn how we might help promote your products to the global IP surveillance market @ ....com" Pretty sure Mac World doesn't have this kind of mission statement . Given the title of the presentation which includes the name of the codec, h.264, it heavily implies such a thing and hence me addressing it. Then it should have been titled at such. As it is, it paints a confusing picture of what is a codec, and what is a storage architectures. As you state here, these are orthogonal concepts and should not be mixed this way. As I noted, I have watched your videos and they are generally high quality. This mixing of topics is an exception. Well, as you know, the cost there is for a lot more than just to record. The light VMS that is inside Mobotix can't support all the functionality that they do. I am not arguing against what Mobotix has but let's not push the message to the point that is hard to defend .

Guys, if you want to become super comfortable for bits and bytes of video (and audio), here is an article to get you there: http://www.madronadigital.com/Library/Audio%20Video%20Encoding%20Formats.html. I wrote it for audio/video people and not CCTV applications but most of it should be useful in this context too.

Helps only in one way - you should have camera with 35 mm format imager On small imager, i thing, you will not gave good result.... Yes, it does require having a camera compatible with a DSLR format (but not the same size sensor -- Canon makes DSLRs with three different sizes from full 35 mm to APS-C size. So there is no requirement to have a 35mm sensor).

Yup. That's why companies like Avigilon use Canon lenses for their high megapixel cameras. While CA exists with any lens especially in the corners, ability to use high-end DSLR lenses helps a lot here.

Hmmm. What I wrote was at least two people's opinion: mine and TheWireGuys. I will expand a bit to add more information here: Avigilon: these folks have cameras that go where others do not. 16 Megapixels anyone? Their use of JPEG2000 compression (in some cameras) gives them neat features like scalability both in time and bandwidth. They now have a newer line augmenting the high-end using traditional compression (H.264). Mobotix: clever architecture using an ARM processor to compress video rather than a separate chip. Advantage: low power consumption (3 watts) meaning you don't need heaters and such for enclosed outdoor cameras. Their hemispheric solution is quite innovative, using a fisheye lens and the dewarping in software to create a linear image. Drawback? Frame rates are not as high as hardware solutions and their high efficiency compression is unique to them. Arecont: You have to be nice to TheWireGuy to explain more than I can about their product . I have known the for quite a while as the bread and butter type of camera without a lot of uniqueness to differentiate them as with the above two. I suspect WireGuys carries it as a more economical solution. So there: you have more of my opinion. Of course, it is still not the whole answer for why you would want to "sell" some of these. You need to figure that out for yourself and your situation (the message from the other guys in this thread). For example, in our business we install cameras in concert with home automation so integration with our touchpanel is important. This makes Mobotix compression method problematic even though I really like their cameras otherwise. We also had a hell of a time getting their attention whereas I managed to get a hold of the right people at Avigilon with one email. In your case, it should be reverse with Mobotix support being better in Europe than US. You too. This forum is quite friendly by the way. You just have to find the right way to ask the question from "senior" members .

DeDanan, I have been reading this forum for a year and every post in that image thread and can tell you that the question you ask, does not have a definitive answer on this forum . Companies carry cameras for a myriad of reasons from margin and support to fidelity. That said, you can actually look under TheWire's signature and find the few cameras which get more up votes than down .

Most definitely a bug. If you were losing entire frames, we could think of other things but not corrupt frames. One final thing though. What is between your PC and the camera? If there is any other device (router, switch, etc), eliminate it and go direct. It is possible that the in-between device is corrupting things.

Then it is a bug . Does it do it with MPEG-4 or is it just MJPEG? If it doesn't, does it let you reduce the resolution you are capturing with MJPEG? If so, try lowering it and see if it helps (for debugging reasons).

What is the speed of the link to the camera? It is possible that it is overflowing its buffer and dropping packets as a result. When you set the quality to 100, you are telling the encoder to not quantize (reduce the fidelity) at all. This can cause pretty massive peaks in data depending on scene content. Try setting the quality to 90 to 95% and see if the problem goes away.

Oh, I don't know, could it have been this ... ... punctuated with video of a bush. Best, Christopher Well, this is what I said after what you quoted: "You might find that H.264 at half to a quarter of the data rate of MJPEG produces the same and maybe even better quality at times. Experiment with above tricks and search for work others have done." I didn't see you having tried either. And I didn't just give you a video of a bush. I provided a pair of videos that showed MJPEG outperforming H.264. And a few others including outdoor road scene.

I said nothing about frame rates. Read my post again. Keyframe distance is not frame rate. I am not writing my answers just for you. I am writing them for everyone. Hence, the advice I gave to investigate these things were general and not take the quickie answer you demanded from me. Your posts did not show evidence that you had tried all the options in H.264. It was devoid of any encoding parameters for example. So I am unclear why you think I should have assumed you had done exhaustive tests of these codecs. A bush that was moving with the exact one in the other codec making the comparison easy and tells you a ton. With motion compensated codecs, it is very hard to do freeze frame comparisons as you did as the very next frame may be sharper than the one you posted. I realize that having a few soft frames may not be good in this application and hence my suggestion to adjust the keyframe distance. Christopher, I was not the one who started the argument with you so don't understand the tone of voice you are using with me. I am not here to answer your challenge or settle a bet. I am here to explain how the technology works. If that is not what interests you, then kindly target your posts at someone else.

And one more which may come closer to the application we have here: Pause the video when the cars go by and see if you can read the license plates.

Well the systems we deal with are complicated so the answer is also complicated. Here is a sample. In any motion compensated codec like H.264/MPEG-4, you can set what is called the keyframe distance. If you set this to say, half a second, then the codec generates a full video frame and compresses it in a similar manner to M-JPEG every 0.5 seconds (or more often as it sees fit). So imagine if I am encoding at 10 fps and I set the keyframe distance to 0.1 seconds. If you do that, then the encoder will essentially degenerated into a fancy M-JPEG codec, generating a full frame of video 10 times a second as M-JPEG would. So if it the motion compensation that you are worried with in these codecs, it can easily be defeated (assuming the encoder gives you that parameter as it should). I say "fancy' because H.264 has a more advanced keyframe compression scheme than M-JPEG. The fanciness comes from two things: 1. A better transform and entropy coder. Compression lingo for it simply being more efficient than MJPEG in how it generates these still frames but with no loss in fidelity. 2. Loop filter. This is a dual-edged source. What this does is that it attempts to soften the compression blocks so that the edges are not visible. I am sure you have seen blocking distortion when data rates are too low. H.264 blends those pixels together. Alas, there is no free lunch and that blending can also remove some picture detail. And H.264 can get quite aggressive in how it does this, providing very pleasing but soft images. Loop filter can be disabled two ways: one is by a flag in the encoder but it is rare to see that in consumer space. The flag is available in professional encoders and some Blu-ray movies for example are encoded with it off. The second way which is kind of indirect is to give the encoder ample bandwidth. The encoder varies the strength of its deblocking filter based on how much compression artifacts exist. If the data rate is very high and there is little to no blocking artifacts, then it doesn't filter much if any pixels. Net, net, if you set the keyframe distance to the timing of your frame rate and given H.264 encoder very high data rate (similar to what M-JPEG would take), you wind up with a better M-JPEG comperssion engine. As the old saying goes, I prefer to teach you how to fish than giving you simple answers that you can't prove beyond asserting it. I will give you the simple answer you want: M-JPEG. But I wish you would do some experimentation as others have done to see if there is a real trade off there. You might find that H.264 at half to a quarter of the data rate of MJPEG produces the same and maybe even better quality at times. Experiment with above tricks and search for work others have done. Speaking of other people's work, there are a ton of consumer still/video cameras now that encode both in MJPEG and AVCHD which is another name for H.264. Youtube is full of comparsion videos, some of which are well done. Check out these samples but before you play them, be sure to click on the pop up in the youtube player and select 720p and select HD aspect ratio. http://www.youtube.com/watch?v=Y3x_lRfuem0 These two are kind of revealing as they are done in a way to bring out differences more clearly. Look at the bleeding on the color wheel in the H.264. Might want to open two browser windows and hit play on both at the same time. PS sure would be nice if this forum allowed embedding of these videos as I can on other forums .

Thanks for asking . I think the answer is complicated . Putting detail resolution aside for a moment, for MJPEG to match H.264 in overall visual quality, you would need 10X the data rate if not more. Invert that and you will have a very poor image at the 10X lower data rate if you used MJPEG. There would be so many compression artifacts that detail will not be recognizable in MJPEG. Now, there is an inverse argument and that is what you are making. Some of efficiency in H.264 comes from built-in filtering. This is designed as to remove visible compression artifacts in exchange for loss of detail. This is what I mentioned in my previous post. To the extent you don't care about low data rate, and could jack up the bit rate until MJPEG is free of compression artifacts, then it will indeed produce a sharper image. So to a great extent, this question has to do with the data rate in use. There are also other variables such as quality of the H.264 implementation (which varies a ton).

There is no way to separate the slow shutter speed which led to that extreme blurring to deblocking filter in H.264 which softens the detail. Indeed, I would say that the slow shutter speed filtered far more detail than the codec ever did.

Can you repost as png files? The compression artifacts from JPEG are the same has three out of four video formats you used.

We tried. The distributor says they are not open to new dealerships in our area.

I installed their player on Win7 64-bit and it ran just fine.

Your observation is correct. Recording does not involve decoding. However, displaying does. I suspect the calculators they used for MPEG-4/MJPEG took into account the fact that someone may be viewing all of those streams on screen. The system they show for Mobotix does not include any station to view said streams. So the whole comparison is improper. That said, MXPEG is much faster to decode than H.264. The drawback is tiling distortion. MXPEG works like MJPEG except that it will not transmit a block it thinks has not changed. The block that has changed gets compressed similarly to JPEG. If there is motion in one block, that would be transmitted and you will see the borders of that block at times. For security applications, that may be acceptable. H.264 has its own set of issues. Even though it looks good for video, it does not always look good when you freeze an image. In-between frames will have distortion that they would not if you had used MJPEG or MXPEG. As cost of H.264 encoding heavily declines (especially in 2 megapixel units), the advantage of MXPEG keeps declining. As to IPacadamy, they provide training for Mobotix so they are either under direct control of them, or make money from selling services to their customers. That said, their work outside of this piece is pretty high quality. I read their newsletters and it has good information not available from Mobotix itself!

I found no samples of video/still images on their web site. The linked images are for their 5 MP cameras and up. Any of you have tested it in the field? I think there are going to be a ton of such cameras, using commodity 1080p encoders which are being used in everything from point and shoot cameras to phones. That should bring down the cost of this performance level.

Ipacademy does decent work with these videos and their newsletter but they are a still a promoter of Mobotix solutions . Mind you, I like the camera but I think the video tells the wrong story. They say that Mobotix compression is cheaper to use because you don't need a PC to capture the video. That is due to the architecture of Mobotix being able to save to a network share, not because it uses their own compression. To wit, if they switched to H.264 tomorrow, everything would stay the same at their end so the argument they make has nothing to do with choice of compression. Real reason Mobotix uses its own compression is that it is a very simple scheme. It simply compares frame to frame and sends out the block that is different. H.264 algorithms also divide the screen into blocks but then can move them without having to retransmit them. This makes them far more efficient that MxPEG that Mobotix uses. The down side is though, as explained in the video, that H.264 is much slower to encode and requires so much more horsepower. Mobotix takes advantage of this by having the main host CPU (ARM processor) also handle encoding. This simply is not possible with H.264 which requires dedicated encoder or DSP. This adds cost but more importantly, generates more heat. See the recently mentioned 3-4 megapixel Sanyo H.264 camera which uses about 7 watts as compared to 3 for Mobotix. The lower power means the housing doesn't fog up as much, and the POE switch doesn't have to put as much juice (running cooler and staying more reliable). There is a cost to this choice though. If you pay attention to Mobotix demo clips, you see how blocks change and the strange look of having the previous frame and current frame mixed up at block boundaries. For high fidelity video, that will be a non-starter, but for CCTV applications, it is fine. One could also make an argument that when the blocks change, they retain their resolution better than H.264 which uses filtering to soften the block edges and hence, reduces detail. Again, for entertainment video presentation, H.264 is a better choice but for this app, an argument can be made that MxPEG is a better choice. What do you think? Should they have hired me to do their marketing material?

Optimal means each sensor producing the same S/N (with differing light levels). I am not asking what the color sensor would do given the same light that the black and white had. But rather, if you take the optimal light level for each setting, is there a resolution difference.

So let's assume optimal response for both sensors: 1. Color sensor during the day with sufficient light to generate solid color image 2. Night sensor with sufficient light to generate solid black and white image Will the resolving power of the two be the same in your opinion?

I think it can be argued that a NAS stays reliable longer and better than a PC, especially one that is shared for some other use (i.e. open to anyone installing anything they want including a media player which may install its own codecs, stomping on the ones you need for the DVR). He is not arguing that sensitivity is increased. He is saying that you either plan the resolution for color or black and white. I think a better answer might be that you get to have more zooming ability during daytime. Whether that is useful or not, is rather subjective and depends on when the possible threats might be.