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

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

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

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

Mfg - 3xLOGIC Model - VIGIL

The problem is DVR's are too general for specific applications like interview recording and therefore kinda .. suck. Please check out http://www.interviewrecorder.com. This is the result of a joint project between 3xLOGIC and Sanyo (at Sanyo's request). 3xLOGIC wrote and owns the software and we currently sell it through a fantastic rep that came to us through our relationship with Sanyo. His name is Carl Bracken. If you check out the site, fill out the contact form and Carl can give you the full scoop on the product. I believe it is in use currently at over 300 sites in the US and it is just starting to take off. While I agree with my good friend Erron that our VIGIL solution is being used successfully in a great many interview applications such as jails and police stations, we would rather you use our specific interview recording application in conjunction with VIGIL simply because the experience will be so much better. Consider that in an interview application you really need these additional capabilities and that is what our Interview software does: • Simple VCR Replacement • Easy DVD Authoring • Easy export in standard AVI format while maintaing authenticated video • Case management with additional documentation • Fully accessible accessible across the network • An interface designed specifically for multi-user interview applications like police stations, etc.. • Specific search capabilities such as Unique Case Number, Offense Type, Investigators Name, Suspect Info, Interview Type, Location, Audience in Attendance, etc.. ..and the list goes on. Digital technology is great and can do a better job than VHS but the point is that you need to pick the right tool for the job. A sledgehammer is great for busting stuff up you but can't use it to hammer in finish nails even though they are both hammers. Cheers.

We record a wide variety of IP cameras (along with analog) and there certainly are big differences in operation and quality amongst manufacturers and even models. IQeye, Arecont and Axis are the most widely used and certainly are very high quality and reliable. There are however many others on the market that are a great value as well and are perfect for many applications. The one thing I did want to point out in this IP vs Analog debate has to do with Megapixel IP. The is no equivalent analog camera to megapixel IP because analog, even high-res, if even recorded at the highest resolution (704x480) is still only 0.333 megapixel. We routinely use 2 and 5 megapixel cameras nowadays and the video is absolutely stunning. Think about it, a 2 megapixel camera has six (6) times the resolution of a high-res analog camera. Erron at 3xLogic wrote this blog entry comparing the cost of megapixel to analog and I think it's somewhat surprising. http://www.3xlogic.com/blog/user/erron/megapixel-technology-too-expensive One of the big issues with megapixel is the size of the images. These articles here talk about recompression which make megapixel usable. http://www.3xlogic.com/aztech http://www.3xlogic.com/megapixel These is some sample video there as well. Dave

Valid comments, unfortunately you appear to have confused frequency with wavelength. IR is longer wavelength (higher nm) therefore lower frequency than visible light. Yep, you are right. I did. Please replace "higher" with "lower" and reread.

I would agree that given enough resources and attention any system can be made rather secure, which it sounds like you have worked towards. The issue is that mainstream corporate America does not. One of my original points was that we have all these people out there buying Linux-based systems because they heard they were more secure but do not have any real possibility of deploying them securely for all the reasons previously listed. As for your OS being on a chip, you are a unique organization since you don't mind cruising around from site to site reflashing each time a security update comes out. Well heck ... you are unique just due to the fact that you apply Linux updates at all. But the truth is that most organizations would not be able to bear the expense of visiting 50, or 150 or perhaps 500 sites to reflash even once a month. In addition, there is great value for our industry thanks to the Windows security update capability because it makes it easier, quicker, and less expensive for 99% of corporate America to deal with. As for the multitude of security flaws routinely discovered in Windows apps such as Exchange, IIS, IE, Media Player and Office .... um ... why would you have those on your DVR? Most manufacturers I know, including my company, use an extremely hardened core configuration of the OS with all non-essential or potentially exploitable apps removed or shut down. In addition, we do not rely on OS resources for external communications, choosing instead to write proprietary apps for external facing activity. We would never even consider running Exchange or IIS so it's not really accurate to compare the security of a Windows-based DVR to a typical office computer running all the typical Windows apps.

Thomas is absolutely correct. Putting the OS on a chip is the opposite of adding security. I believe what you are thinking is that if the OS is locked in stone that other programs can't come along and change the OS code which is correct, BUT that is not the problem. The problem is that the OS's already have the exploits built into them .. they just have not been discovered yet. Everyday new ways to attact the OS are discovered so we have to respond by releasing patches to fix the vulnerability. Having your OS in firmware means that it you have to go out to every location to re-bake the OS onto the firmware for every patch. Not likely to happen on a regular basis as is required for effective patching. Also, you are thinking that the security of the OS itself is the goal and it's not ... it's the security of the data that resides on the system as well as the ability to gain root access to the system so that further control of your network can take place. In other words, if I am an attacker and I cannot change the OS code because it is in firmware, it make no difference to me if I have the ability to log into the system with root access, obtain all the data in the system and poke around your businesses network. As for the number of flaws discovered in Windows vs Linux, you are right .. over time more flaws have been discovered in Windows due to the large amount of people working everyday to find them by trying every combination of hacking possible. But the fact remains that Windows flaws are historically resolved and deployed much faster than Linux flaws, most times before they are exploited on a wholesale basis. I will again restate what people don't seem to realize ... The greatest security threat to your network and your data really have very little to do with the OS and much more to do with the applications and how they are deployed. Windows greatest threat has been Outlook. If you take the Microsoft applications, including web applicaitons, out of the picture an argument could certainly be made that Windows is ultrasecure by comparison. I will also restate that most of the Linux DVR's being sold are manufacturered in asia, and the people who buy them have no clue what open-source version of Linux has been used, have no idea what patches are missing, have no idea what additional software is running in their DVR, and certainly have no idea where to get patches or how to apply them. This makes these "solutions" an obvious problem for corporate security.

I think your logic is flawed for several important reasons: 1) Both operating systems present a variety of on-going security flaws. 2) Most of the flaws discussed in the Windows vs Linux debate revolve around applications and not the OS itself. 3) Nearly every discussion out there is comparing Linux/Apache against Windows/IIS which is totally inaccurate for Windows-based DVR's that have all commonly exploitable technologies disabled. 4) Most Windows implementations are managed in some fashion, with many setup for automatic update. 5) I've yet to find an end-user who regularly applies Linux vulnerable security patches to their DVR's or their Linux-based IP cameras. Do most end-users even know which open-source group provided the Linux build they are using? Would they know where to go for the patches they need? You may think from the above that I am plugging Windows and really I am not. My argument is that the end-security of a product actually has very little to do with the OS it is built on and EVERYTHING to do with how the manufacturer built it, how it was installed and how it is maintained. Here are some important questions to ask: Does the manufacturers’ development process have security considerations built into the architecture, the code and the solution as a whole including how it is deployed and maintained? Manufacturers that provide secure products spend incredible amounts of money considering the how their application interacts with the OS, how it is going to be deployed and thousands of other considerations including who has access to the code and so forth. How do you know that the Linux DVR you bought from Korea or China does not have a Trojan or back-door? Does the manufacturer really understand the architecture of your network? Do they understand your governance requirements? Do they understand how you maintain your installation? Did they provide training and guidance on a secure installation? Do they regularly communicate with you when someone reports a security flaw? What is the manufacturers’ implementation of the OS? Is it some off-the-shelf package that has not been hardened? Does it even have the latest OS code installed? Many of the installations I see contain old unpatched code .. right out of the box. It doesn't matter if it's Windows or Linux. If it comes out of the box with exploitable software .. it's exploitable. Did the manufacturer rely on commonly exploited technologies? Some manufacturers build the entire user interface including the remote client from proprietary technologies. Some manufacturers rely on web-browsers, web servers, and dozens of services provided by the operating system for which vulnerabilities are routinely discovered. This applies to BOTH operating systems. Does it run a web server on the DVR for remote access? Regardless of the OS, web applications are the single most vulnerable and exploited technology today and in fact the maintenance burden (meaning how much time you must spend to keep it secure) is phenomenal. You might have it super secure today, and yet by tomorrow morning a new flaw will have been discovered. Again this applies to both OS's. Does your DVR have port 80 open? Does it allow remote access using or relying on OS resources? This is the single most overlooked issue when trying to select a secure solution. This list could go on, but again, my point is that in my (not so humble?? ha ha) opinion is that OS selection has so very little to do with the security of one DVR against the other. It has everything to do with software, configuration, architecture, deployment and maintenance.

Excellent addition and very informative. I certainly had forgotten about the limitations of the NTSC format as well! Thanks for your input.

IR response really has nothing to do with price. Sometimes it's the cheapo black & whites that have the best IT response. It's mostly dependant on the chip/ Mfg's used to share the spectral response of their chips. I don't know it they do this anymore. But here's the deal .. the higher in frequency (more towards infrared), the less the camera will see it. But if it's a black & white it will probably still see it, it's just a matter of how lit up the area would be. So here's a few simple rules: 1) The more covert you want the IR lighting to be (meaning people think they are in the dark and can't see light coming from the IR illuminator) , the higher the frequency (i.e. in the 800-900nm range). 2) The higher the IR frequency, the less responsive the camera will be to it. 3) The only way to overcome high-freq/low-response is to flood the area with more IR light meaning more power. It's like looking at your room with sunglasses on. If you use high frequency IR you have very very dark sunglasses on so you need very strong light to see. If you use lower frequency IR you still have sunglasses on but you don't need as much light to see.

Keep in mind that not all black and white cameras have the same IR response either. As you get up into the higher frequencies of IR (more invisible) you'll find that there are even some b&w that have minimal response. That's why most simple IR applications use IR in the 800nm range instead of 900nm range because it is closer to the visible light range and therefore most all cameras will see it.