Love MJPEG but hate large file sizes?

[dnieweg 0]

Just posted the results of our tests with the new IQeye 775, 5 megapixel camera. Here is our new blog article at 3xLOGIC where you can find sample clips from the IQeye.

 

http://www.3xlogic.com/blog/user/3xdave/iqeye-and-3xlogic-perfect-match-technology

 

Comments welcome.

 

Dave

[thewireguys 3]

IQI is the one camera manufacture I have yet to try. Just can't find a reason, they're not cheaper and I haven't seen a image from one of there cameras that I was impressed with. What is the deal? Tell me why I should try IQI cameras.

[rory 0]

Looks good, Im almost sold. " title="Applause" />

[buellwinkle 0]

They very local to me, 5 miles away, but haven't really looked at them. I was told they are made in China. I wrote an email to them asking if it's true and they never responded. My impression from them was that their "pro" series is a little pricey and they seem to offer the same sort of NVR software built into the camera thing that Mobotix does. Also, no 775 model on their website, but their pro-line goes to 5MP and their Sentinal is their outdoor camera.

 

I know Rory can appreciate a $1,700 IP camera the most here So my ACTi at $500-600 doesn't sound so expensive now

 

Also, their 5MP cameras on their website are JPEG or H.264, so don't know why the OP is comparing MJPEG compression when H.264 is available and would likely have better compression than what he's comparing it to.

[ak357 0]

 

Also, their 5MP cameras on their website are JPEG or H.264, so don't know why the OP is comparing MJPEG compression when H.264 is available and would likely have better compression than what he's comparing it to.

 

OP has good reason to compare

Do u know or understand difference between H.264 and JPEG ?

[Soundy 1]

Also, their 5MP cameras on their website are JPEG or H.264, so don't know why the OP is comparing MJPEG compression when H.264 is available and would likely have better compression than what he's comparing it to.

If you read the actual link, you'd know why... in fact, the section is even called, "The Why":

 

Even with the dominant presence of h.264, there are still many reasons you will still want to specify MJPEG cameras, or at the very least, be required to use MJPEG either because of existing infrastructure, or the demand by clients for large high-quality megapixel cameras.

The reasons many IP megapixel cameras today still use MJPEG as their primary video compression method over h.264 include:

- Better image quality, especially at lower frame rates

- Less processing power needed both in the camera and for decompression in the client applications

- Consistent frame size for high-movement scenes

IQeye Invision for example, has long been regarded as one of the leaders in image quality and as a result has been a staunch proponent of the advantages and quality of MJPEG compared to the current industry favorite H.264, although they manufacture both type of solutions. In fact, their commitment to MJPEG continues today with the release of newer breeds of high-performance MJPEG megapixel cameras designed to provide among the best video quality in the industry.

 

One of 3xLogic's engineers stated to me that Aztech CAN, in some circumstances, compress BETTER than H.264... if that's not "why" enough, I don't know what is

 

I haven't had the chance to test that claim yet, mostly for lack of H.264 cameras to play with... I should test it with this Pelco Sarix dome I have here; one thing for sure, it's a prime example of the extra processing power required: decoding the full-blown H.264 stream is bogging the $#!+ out of my test NVR.

[rory 0]

I know Rory can appreciate a $1,700 IP camera the most here

Yeah thats a little pricey

though if it can see in pitch dark up to 100' and ID licence plates then it could be worth it .. .

[thewireguys 3]

One of 3xLogic's engineers stated to me that Aztech CAN, in some circumstances, compress BETTER than H.264... if that's not "why" enough, I don't know what is

 

I haven't had the chance to test that claim yet, mostly for lack of H.264 cameras to play with... I should test it with this Pelco Sarix dome I have here; one thing for sure, it's a prime example of the extra processing power required: decoding the full-blown H.264 stream is bogging the $#!+ out of my test NVR.

 

Yes I have heard that from multiple people about Pelco. Arecont uses less CPU with h.264 then mjpeg.

[buellwinkle 0]

I know Rory can appreciate a $1,700 IP camera the most here

Yeah thats a little pricey

though if it can see in pitch dark up to 100' and ID licence plates then it could be worth it .. .

 

No camera can see in pitch dark without some sort of illumination aid. What many cameras do to see in very low light is they increase the amount of time the shutter is open, like Arecont Moonlight mode that slows the shutter down to 1/2 second. It's facinating to see that clear image at night and kudos to Arecont for the noise reduction until you realize that a turtle walking across the screen is just too blurry to ID . I set my cameras up to 1/30th of second minimum because above that, a person walking will be too blurred to ID, but you can put a sign, "please standstill and smile for the camera".

 

As for MJPEG vs. H.264, my testing with Axis shows that MJPEG, unless set to the lowest compression setting (100% on Axis), it's going to have compression artifacts, many of which makes a face harder to ID. H.264 from what I've seen actually had less compression artifacts than MJPEG at 100% when I blew up the stills. What I found is that H.264 varies from model to model, even under the same manufacurer. H.264 was significantly better on an Axis M1114, it was actually worse on a M1031. To me the case for MJPEG is that it works on my iPad, H.264 does not.

[Soundy 1]

...until you realize that a turtle walking across the screen is just too blurry to ID .

I didn't know facial recognition worked on turtles!

[dnieweg 0]

Couple of comments

 

@thewireguys - Not trying to pitch IQeye specifically - It's just one of the many cameras we record and recompress, but for those who do use IQeye or have to respond to an IQeye bid spec, it's nice to come in with a low price for the NVR by using up to 90% less storage while providing the same amount of video. Fact is we can do the same thing with any MJPEG stream from nearly any manufacturer. It's just what we do. Here's a few of the cams we support: http://www.3xlogic.com/ipcameras (List is always out-of-date by the way)

 

Just for the record, I do happen to know that IQeye recently dropped their prices significantly. By as much as 60% on some models. Might be worth checking into. Again, we have nothing to do with IQeye other than we record their cameras.

 

We do the same thing with the Arecont 8180 by the way. That camera produces ridiculously large file sizes and when compressed with Aztech they start coming in at about 30k depending on the scene. I think I'll run a demo to show this on my next blog post.

 

@buellwinkle - We are not made in China. LOL - Our engineering department is in Victoria, BC (Canada) and US products are built right here in Westminster, Colorado. If you are only 5 miles away, you should drop in. Also, we have nothing to do with Sentinel. Since you mentioned it, Aztech does in fact produce smaller file sizes and better quality than h.264 (at lower frame rates). See below. Lastly, we are not limited to 5 megapixel whatsoever. A new company, Arktan Systems is getting ready to release a 21 megapixel camera and is using 3xLOGIC VIGIL software to demo their cameras because we are able to recompress the large files into very small ones.

 

Speaking of h.264, we use a lot of this as well, for specific applications anyways. We use h.264 to compress analog cameras on our PRO Series hybrid units simply because the hardware encoder chips are inexpensive and work well. But on those same units you can also choose to record IP cameras with the Native compression from the camera or recompress using Aztech.

 

As great as h.264 has been for our industry, there are some drawbacks in certain situations. This is what we use Aztech to overcome (in addition to overcoming large MJPEG files). In no particular order:

 

1) h.264 was created for real-time video. It works great at 30 fps, but as you start decreasing the frame-rate your files sizes start going way up and the artifact, especially in areas with motion, become increasingly prevalent.

 

2) h.264 cannot be natively streamed into a browser or mobile appliance limiting it's ability to be easily consumed by the wide-array of applications available.

 

3) h.264 requires a reasonably significant amount of processor power to decode meaning even those apps designed to consume specific flavors of h.264 on low-power appliances (think mobile) often perform very poorly. Even on a desktop PC, you need rather decent video processor support and memory if you wish to display large amounts of individual streams at moderate or higher frame-rates.

 

Again, as much as we love h.264 and use it quite frequently, we saw a need to be able to take video from any IP camera (be it h.264 or MJPEG) and allow it to be recompressed for effective streaming to mobile, network devices and disk.

 

Just so happens in the case of MJPEG we can also provide huge storage efficiencies.

 

When comparing h.264 to Aztech, if you are recording at 10fps or less, you are going to find that Aztech produces file streams that are much smaller than h.264 and you will also find that the video quality is substantially higher.

 

When recording at 30fps you will find that Aztech and h.264 are very much equivalent in both file sizes and quality.

 

Great discussion. Thanks.

 

Dave

[rory 0]

No camera can see in pitch dark without some sort of illumination aid. What many cameras do to see in very low light is they increase the amount of time the shutter is open, like Arecont Moonlight mode that slows the shutter down to 1/2 second. It's facinating to see that clear image at night and kudos to Arecont for the noise reduction until you realize that a turtle walking across the screen is just too blurry to ID . I set my cameras up to 1/30th of second minimum because above that, a person walking will be too blurred to ID, but you can put a sign, "please standstill and smile for the camera".

Ofcourse I meant using Infrared in pitch dark.

Also, ive used low light cameras and never had to slow the shutter, but they werent IP cameras.

[ak357 0]

When recording at 30fps you will find that Aztech and h.264 are very much equivalent in both file sizes and quality.

Great discussion. Thanks.

Dave

 

Thx for info Dave

few ??? for you

 

from your article

"As we receive these large images,

the VIGIL software decompresses the image file, and then recompresses the image

using our special Aztech codec"

 

How decompress and re compress every frame of every camera affect CPU usage ?

Snapshots of Task manager -- Performance would be nice

Running 10-20 Megapix cam full blast please

Thanks

[thewireguys 3]

Also since your still streaming mjpeg your product is designed to help with storage and remote clients? LAN bandwidth is not reduced from the cameras to the NVR. Is my thinking correct?

[ak357 0]

Also since your still streaming mjpeg your product is designed to help with storage and remote clients? LAN bandwidth is not reduced from the cameras to the NVR. Is my thinking correct?

 

That was my second question

[dnieweg 0]

Great questions.

 

@ak357

Definitely decompressing and recompressing is CPU intensive which is one of the reasons our DVR/NVR's are reasonably powerful, and we also offer power upgrades for special situations. You are not going to recompress 16 or 32 Arecont 8180's (8 MP) with the standard hardware, but you can do a few and a several 1.3 MP and of course all the analog are hardware compressed so they do not task the processor. A task manager shot is a good idea.

 

@thewireguys

You are absolutely thinking correctly. From the camera to the NVR/DVR doing the recompression, the file sizes are not affected so they are still very big. But of course this is the case regardless of which VMS/NVR you are using. Internal LAN bandwidth is not generally as much of an issue as internet bandwidth. And yes, we are streaming and storing in MJPEG .. and that is exactly the point, our MJPEG codec is radically different than any other MJPEG codec. We take in standard MJPEG and compress to Aztech MJPEG which you see is 50-90% smaller.

[thewireguys 3]

Great questions.

 

@ak357

Definitely decompressing and recompressing is CPU intensive which is one of the reasons our DVR/NVR's are reasonably powerful, and we also offer power upgrades for special situations. You are not going to recompress 16 or 32 Arecont 8180's (8 MP) with the standard hardware, but you can do a few and a several 1.3 MP and of course all the analog are hardware compressed so they do not task the processor. A task manager shot is a good idea.

 

@thewireguys

You are absolutely thinking correctly. From the camera to the NVR/DVR doing the recompression, the file sizes are not affected so they are still very big. But of course this is the case regardless of which VMS/NVR you are using. Internal LAN bandwidth is not generally as much of an issue as internet bandwidth. And yes, we are streaming and storing in MJPEG .. and that is exactly the point, our MJPEG codec is radically different than any other MJPEG codec. We take in standard MJPEG and compress to Aztech MJPEG which you see is 50-90% smaller.

 

So H.264 is still better for LAN traffic because you are still compressing at the camera. Sounds like you guys need to start implementing this on cameras for you to get a lot of market penetration.

[ak357 0]

Great questions.

 

@ak357

Definitely decompressing and recompressing is CPU intensive which is one of the reasons our DVR/NVR's are reasonably powerful, and we also offer power upgrades for special situations. You are not going to recompress 16 or 32 Arecont 8180's (8 MP) with the standard hardware, but you can do a few and a several 1.3 MP and of course all the analog are hardware compressed so they do not task the processor. A task manager shot is a good idea.

 

@thewireguys

You are absolutely thinking correctly. From the camera to the NVR/DVR doing the recompression, the file sizes are not affected so they are still very big. But of course this is the case regardless of which VMS/NVR you are using. Internal LAN bandwidth is not generally as much of an issue as internet bandwidth. And yes, we are streaming and storing in MJPEG .. and that is exactly the point, our MJPEG codec is radically different than any other MJPEG codec. We take in standard MJPEG and compress to Aztech MJPEG which you see is 50-90% smaller.

 

No wonder Soundy and 2 Canada's major oil companies

love Vigil

1 fps and lots days of storage

just joking

 

My problem is I can't stand low frame rate

We all started long time ago with few fps

but in 2010

10-15 fps or more

 

I have too many real life examples when low frames

leads to lots of problems,complains and so on ....

[dnieweg 0]

So H.264 is still better for LAN traffic because you are still compressing at the camera. Sounds like you guys need to start implementing this on cameras for you to get a lot of market penetration.

 

Yes. If you have limited LAN (internal) bandwidth h.264 would be better. But most IP cameras are run directly from the cameras to the switch and to the NVR/DVR and most switches today are at least 100mb and some 1000mb so LAN bandwidth is not normally an issue. WAN (internet bandwidth) is an entirely different story however and can benefit from both h.264 and Aztech.

 

Please understand, we are not pitching MJPEG, nor are we pitching h.264. Each has good things in some areas and bad and it depends on the application. We don't make the IP camera's. Our job is to provide a robust toolkit that allows beneficial use of all the different types of video streams we are being asked to record.

 

For example, because we see so many benefits for IP megapixel it would be easy to say that analog is worthless, but we would never say that because there are still many places where analog makes perfect sense. That is why Hybrid is so important. So you can put very inexpensive cameras in small hallways, rooms, back doors etc, and still use a 180-degree 8MP camera to watch the parking lot or the front-end of a store.

 

Same thing for h.264 and MJPEG. You might have 20 h.264 cameras, and then use a 21 megapixel camera from Arktan Systems for one very wide shot, or like I said an Arecont 8180, or even a 360-degree top-down to see the entire room. These are only available in MJPEG simply because the manufacturers of those cameras find it would be way too expensive to implement h.264 becuase the processor would not fit in the camera. lol

 

Same thing with frame rate AK357 ... I also love normal speed video, but we would be foolish to think every camera in every location had to be 30 fps when it is not needed. Again, we don't make the camera. We simply record the cameras that the people are buying the most efficient way possible with the best quality. This is what is important we believe.

 

BTW - Thanks for the intelligent questions.