dnieweg

Thanks Rory. Awesome comment.

Hi Matt, I realized the thread was a bit dated right after I hit send. LOL Still relevant info anyways. It is surprising how well these little MVR's perform. Glad you got a chance to use a few of them. Keep up the good work!

FYI 1) The MVR runs an ATOM 525. 2) There is both a Hybrid model and an NVR model. 3) The NVR easily supports up to 16 2 megapixel cameras. It will actually support larger cameras as well, such as 5mp, 8mp and 20mp versions from Arecont and other manufacturers. While I believe you will be fine with one or two of these larger megapixel, there is no way you are going to run 16 20mp cameras on this unit. Understand much of our application core was written in assembly language to allow more power on a lower processor .. but even this has it's limits. 4) We also support our analog hardware-encoding capture cards in 4, 8 & 16 channel units. These compress your analog cameras using H.264 and since the compression is done on the capture card, it does not load the Atom processor. 5) The unit current support up to 2TB of internal storage.

Matt, Xellbuy gave me a call this morning and I recommended sticking with analog. It looks like you are recommending as well. I said SuperCircuits or Ebay would probably give him the best bang for the buck. I did not have a recommendation for a low-cost, good quality DVR. You have anything you would recommend? A Hik embedded unit or...? Hope all is well. Dave N / 3xLOGIC

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.

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.

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

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

I was one of the founders of Teknovation before it was purchased by DigitEyes. The AVX was one of our products. I'll ping my old coworkers and see if they can remember. Are you talking about the Windows password or the DVR software password?

Here's an updated list of the IP cameras that VIGIL from 3xLOGIC supports. http://www.3xlogic.com/ipcameras

RR, Change is hard ... lol If your video looks choppy and the video quality is not great then I would have to disagree with you and say that your system even though it is digital and only one year old IS OUT OF DATE! There is no reason for video to look choppy today, in fact it should look better than the new 1080i HDTV if video quality is important (megapixel). Again, the Interview Recorder is built on a high-def hybrid DVR technology, but the software is entirely different and specifically designed to make it easy to capture, review and create DVD's of interviews with high-quality video and audio. You are just trying to use a basic "old" technology digital recorder to do something it was obviously no designed for.

The .exe is obviously a Windows program and not designed to run on the mac. Some remote clients will run on a Windows emulation package such a Parallels (our does), but what you most likely have is a white label Asian import. For some reason I've found Asian applications can be quite finicky and barely run on the targeted Windows platform. Good luck.

Mfg - 3xLOGIC Model - VIGIL

Mfg - 3xLOGIC Model - VIGIL

Mfg - 3xLOGIC Model - VIGIL