Disqus - Latest Comments for dloher

Re: DVR vs VMS Software: Test Results

Darren Loher — Wed, 30 Mar 2011 11:30:57 -0000

I'd like the point out that it's possible to have VMS features with DVR's. Some of the industry jargon out there for NVR's, VMS and DVR is somewhat limited.

Envysion has been making it's own DVR's (PC based Linux Appliances, not custom) for a long time now, but has always had the Enterprise management focus on the software. The whole, lots of remote locations managed centrally is most cost effectively accomplished with DVR's at the edge which are all tethered to a centralized management system. This really helps keep the complexity down when managing 1,000's of remote locations. The low cost for analog cameras and capture cards combined with entry level PC hardware for DVR's is a great combination. Granted, some of the very low cost, purpose built DVR's are even cheaper than the PC based hardware we use, there are big limitations on what software can be installed on those.

What I'd really love to see someday is a standard API for interfacing to video recorder appliances. If there were standard ways to talk to a DVR over the network for video searching and playback, I think there'd be a lot of benefit to customers who want to pick a VMS/CMS platform and then use the hardware of their choice at the edge. That model has worked well in the IP networking world for routers, switches and network management software.

Re: Video Surveillance as a Service (VSaaS) Comparison 2010

Darren Loher — Tue, 24 Aug 2010 13:55:02 -0000

Nice updated review, I think the number of options is starting to beg for a matrix of providers and features with perhaps ratings based on applications.
Applications could be:

Residential
1-4 cameras
5+ cameras

Commerical
1-4 cameras
5+ cameras

You could further break out the applications with features like
- bandwidth required (broadband, high-end broadband, dedicated line)
- Integration
- CMS
- Access Control
- Point of sale
- Total system scalability
- number of cameras
- number of recorders
- number of locations

Re: Does the Market Want Closed IPTV?

Darren Loher — Thu, 29 Jul 2010 20:38:34 -0000

Hi Todd,
Regarding IP vs analog, I agree. Nearly all our customers don't care which is used. We mostly deploy analog due to cost. I just figured this was a discussion about how to configure IP cameras. :)

Re: Does the Market Want Closed IPTV?

Darren Loher — Thu, 29 Jul 2010 11:12:32 -0000

The market definitely wants plug and play IP camera systems. This is especially true on smaller systems where the overhead of installation, configuring and managing the system need to be very small. If one is selling 1-10 small systems to a non-technical end user, they aren't going to care if it's proprietary or not. They are just going to care if they can get the price and functions they need.

Now if you're selling/installing 5,000 small systems for a variety of customers, not being locked into a camera vendor becomes more important.

Since one can do auto discovery and auto configuration of IP cameras using non-proprietary methods, I'd certainly vote against a proprietary method.

FWIW, Envysion uses the Zeroconf standard to auto detect and then develops custom scripts to configure cameras. Several IP camera vendors support zeroconf. Writing the scripts is not that much work. I've written ours for configuring Axis and ACTi and we're talking less than 2 weeks of work for one person. Now that we have the framework for this, the time is probably down in the 2-5 days depending on the manufacturer. We'll probably use ONVIF/PSIA someday if/when they mature.

Re: Is Integrating PoS and Video Surveillance a Good Idea?

Darren Loher — Thu, 04 Mar 2010 13:59:30 -0000

In retail, the POS system is typically the most important and useful data system for their entire business. Being able to interface this with video is obviously extremely valuable.

Beware that a lot of vendor's POS integration is simply a text overlay on top of video. I suppose that counts for something, but does not make the POS data searchable or reportable. Without being searchable and reportable, most of the benefit of integrating with video is lost.

As far as how difficult it is to integrate, well, it isn't very easy. The POS market is very fragmented. Radiant and Micros seems to be among the dominant vendors in quick service retail, but collectively still only hold a small percentage of the market for quick service retail. Other retail segments use entirely different POS vendors. Even within a particular POS vendor, there are often several versions of their products, including simply different versions of code that change the data they output.

Further, each customer often will customize their implementation of their POS in ways that require at least some customization if you want to do reporting. With rich capabilities in one's video system to interface with POS, adapting to these customizations is not a major ordeal.

Once you've integrated however, there are big benefits to the customer. With a good software framework, integration is quite a bit easier. It's taken Envysion 4 years to get where we are with POS integration. Often we can integrate data feeds with new point of sale systems in 2-8 weeks.

Re: Should Stolen DVRs Motivate a Move to VSaaS?

Darren Loher — Fri, 26 Feb 2010 16:53:41 -0000

Hi Mr. Avidan,

Maybe you could hook up Mr. Honovich with a demo system to do a report on? I'd like to see the results of 4 cameras remotely recording using 256Kbps on a pre-existing 384Kbps uplink in an SMB scenario.

Re: Should Stolen DVRs Motivate a Move to VSaaS?

Darren Loher — Thu, 25 Feb 2010 16:13:21 -0000

We wholly believe in local recording. However, we also offer an ability to add remote recording while also locally recording. We can locally record at high quality and remotely record at a different, usually much lower quality or reduced number of cameras.

The bandwidth cost for small remote locations just doesn't make financial sense given the loss being protected against unless the camera count is very small and the quality required is very low.

Now something that I can see remote recording being used for in a financially sensible way is residential use for 1 or 2 cameras where the residence already has high end broadband connectivity (over 768Kbps uplink). If you're only using 256Kbps uplink for say 1 or 2 cameras, you can probably get away with sharing the existing broadband link with only a small penalty in performance to the customer's other network usage.

This sort of setup may still violate the acceptable use policy (AUP) for many ISP's. It is common for residential Internet services to be *very* constrained on the total uplink capacity coming out of neighborhoods. Just a few "abusers" of the policy in an area can cause problems for the neighborhood. ISP's faced with issues like that will start to take action.

Re: Guidelines for Testing IP Cameras

Darren Loher — Thu, 25 Feb 2010 13:21:11 -0000

Agreed, those are issues to testing jitter, which is a tricky thing to measure consistently and fairly. In the digital video broadcast world, there are hardware test sets for this sort of thing that are very pricey. They also require a standards formatted video stream, such as ASI/DVB. Since we in the IP CCTV world don't have standards or test sets like that (that I am aware of), it will be harder to get a consistent and fair test across vendors.

I am not sure if there are industry best practices for jitter in surveillance applications. Do you know of any?

Here's what I do:
- Use the same test client hardware (same PC)
- Minimal network - 1 Ethernet switch with PC and camera directly connected
- Stream video using the camera manufacturer's video streaming client of choice (most have an Internet Explorer based Active-X control).
- Stream using 3 or 4 common profiles, for example:
-- 1280x1024 at 5fps
-- 1280x720 at 5fps
-- 720x480 at 5fps
-- 640x480 at 5fps

I tune the camera settings to achieve about "half a frame time" of jitter per second as that seems to "good" to our customers. (100ms at 5fps) A full frame time of jitter is the upper limit and is perceived by our customers as "barely acceptable, not very good". On the few cameras I've tested, many cannot meet this half-frame time requirement at 1280x1024 5fps using MPEG4 (that is, 100ms, I often encounter 200-300ms of jitter or more. Of course, that is just me 'eyeballing' it).

Of course, there are numerous other factors such as VBR, CBR and which bitrates/compression settings are used. I have just had to spend time to attempt to get a "good" balance of quality versus jitter. I don't have any generic tools to actually measure this with any precision. It's all just me staring at the screen and estimating if the jitter is "bad enough".

Not very scientific, but it's what I have to work with for now. :)

Re: Guidelines for Testing IP Cameras

Darren Loher — Wed, 24 Feb 2010 11:24:55 -0000

I was wondering if you could include smoothness / jitter of playback as standard criteria in your Megapixel camera tests. In the few megapixel cameras I've tested, I've noticed that the framerate is not very consistent resulting in a video that has a high jitter in the frame rate that some customers (the less technical ones) find annoying or confusing to watch. Since nearly all our customers are not video surveillance folks, this is something that bothers them enough that they would rather run lower resolution believe it or not. :)

Re: Is ADT Over-Selling IP Video?

Darren Loher — Fri, 11 Dec 2009 16:15:28 -0000

I love IP cameras, the technology is really cool. I've enjoyed implementing IP video here at Envysion. But hard as I've tried, there are not many scenarios where IP cameras are lower cost than analog. This seems to be especially true in small footprint systems.

So far the only use of IP cameras from our customer base (which is very cost sensitive) the use of Megapixel cameras. Due to the costs though, our customers pick and choose only very few problem areas to use megapixel.

Re: Is Hacking IP Cameras A Major Risk?

Darren Loher — Tue, 18 Aug 2009 15:11:54 -0000

Hacking video surveillance systems which are accessible via an IP network is a very major risk that can be safely mitigated. IP cameras increase this risk because there are more devices which are accessible over the network. Most cameras do not have sufficient security mechanisms built in and therefore require the network and VMS they are connected with to provide layers of security on top of the camera.

I believe VMS and IP cameras can be made very secure, but most of the systems require configuration and periodic auditing to verify they are in fact secure.

Re: What's the Future of SD Cards for Video Surveillance Storage?

Darren Loher — Tue, 18 Aug 2009 14:41:49 -0000

Currently all SSD technologies degrade over time. In in a surveillance application, it will be interesting to see how well SSD will work long term when being written to constantly.

Re: Top 5 Problems of Managed Video Surveillanca / SaaS

Darren Loher — Thu, 09 Jul 2009 11:07:14 -0000

Agreed! I am a fan of distributed storage when the lowest cost is needed. If one DVR/disk fails, you only lose that one chunk of video. That is a lower risk scenario than losing all of one's video or video for many locations. Granted, a similar redundancy strategy could be done for centralized/hosted storage. But the market doesn't deliver a low cost commercial solution at scale. (there are open source and do it yourself IT solutions though)

Re: Top 5 Problems of Managed Video Surveillanca / SaaS

Darren Loher — Wed, 08 Jul 2009 18:22:05 -0000

Indeed! Expensive leased lines have pretty good reliability and are likely acceptable for many customers. But broadband is a different story. Business grade broadband can be pretty good, but in my opinion, may fall short of customers expectations, depending on how critical their access to video is.

Cameras with onboard storage storage may be cost effective in locations where there are few cameras or there are special requirements or restrictions that make an on site DVR box expensive. There are real use cases for that.

But for the general case, commodity prices for DVR drives in the 500GB - 2TB size are near impossible to beat for cost/GB. Leveraging on site storage really helps keep scale of storage in the sweet spot for cost.

These days, if one goes over 6-12TB of storage the cost per GB actually starts to go up. Centralized/hosted video storage of course faces those issues. An iSCSI NAS can be 8-12x the cost of a single disk at a remote site. (or 4-6x the cost of direct attached RAID up to about 12TB at the local site)

Re: Top 5 Problems of Managed Video Surveillanca / SaaS

Darren Loher — Wed, 08 Jul 2009 18:00:23 -0000

Storing video on site but still offering a hosted VMS system is not a barrier and resolves the most costly of the limitations: bandwidth and storage scaling. And it's not just the last mile bandwidth. Data center bandwidth costs money too.

As far as networking complexity by having storage on site, that is an issue faced by both DVR's, NVR's and managed solutions. Remote video recording actually does not really help this problem and makes for a much less reliable system that is highly vulnerable to network glitches. Most network providers perform maintenance in the evening hours, often taking networks offline or causing high latency and packet loss which would be detrimental to remote recording.

DVR appliances that can auto-connect to the hosted data center and be 100% remote controlled radically reduces the issues with network configuration. There are a few network tricks to help make this possible, but Envysion has been doing this at scale for over two years.

As far as the value proposition, managed video solutions aren't always the right solution. If video is not used remotely, there is a lot less value for a managed video solution.

Re: IP Video Industry Weekly - June 26th

Darren Loher — Tue, 30 Jun 2009 12:07:42 -0000

The mydlink service requires registration to D-Link's hosted web portal, which since one must buy the camera from D-Link, one might characterize as a lifetime prepaid subscription. It's a good idea though.

Regarding the security issue on Cisco: I am sure there are many vulnerabilities for IP video products of all kinds. Cisco has an excellent history of dealing with security issues for IP network products. They provide fixes and disclose the issues. This is a standard business practice that all mature information technology companies should be doing. Public disclosure is performed after a fix is available and normally well after customers have been notified.

The lack of announcements from other manufacturers does not indicate they don't have problems. It indicates they are not talking about them.

Re: Can Everfocus Make Megapixel Simple and Inexpensive?

Darren Loher — Tue, 30 Jun 2009 11:39:53 -0000

I see this as a challenge for the IP camera providers to accelerate their efforts to make IP cameras as plug and play as the HDcctv cams are.

It's possible to do it now as a few VMS providers have done with certain cameras. But we need all the IP camera manufacters to get on the same page so auto configuration 'just works' no matter which IP cam or VMS a customer buys.

Re: Should You Use Cameras With Built In Storage?

Darren Loher — Mon, 22 Jun 2009 17:36:45 -0000

Compact flash also has a limited lifetime and some variants become slower (perhaps too slow) over time as they are written to. This is not an issue with digital cameras, but in 24x7 video recording, compact flash is likely to have a pretty short lifetime. How short probably depends a lot on the specific CF card one is using.

Anyone have real world experience with 24x7 video recording to compact flash?

Re: HDcctv: Non-IP Megapixel Coming to Video Surveillance?

Darren Loher — Wed, 20 May 2009 12:56:01 -0000

IP cameras can be auto configured with a good vms system. we at Envysion implemented auto-discovery and configuration in less than 30 days for Axis IP cameras. Using zeroconf and a simple http api we can now do it in just a couple days and push the software update into production automatically.

Ethernet can run over coax (IEEE 10Base2 is based on rg58 (50ohm), but with tweaks can run on rg59 (75ohm). There are a number of products that do this now, but they are currently a bit clunky and perhap too expensive. But that can be fixed. Just need some IP cameras with an integrated Ethernet over rg59 interface to get the cost down and provide a clean install.

Re: Testing the Axis Q1755 HD Surveillance Camera

Darren Loher — Tue, 21 Apr 2009 19:57:09 -0000

Given the extremely high bandwidth for MJPEG at these resolutions, you may be seeing greater CPU utilization for MJPEG due to the CPU and Memory bus speed on your PC/laptop. That could be quite common with many PC's, especially laptops which usually have much slower front side bus (FSB) speeds than desktops.

Perhaps with a higher bus speed you might see MJPEG start taking less CPU than H.264. Just a guess.

Re: Is Bandwidth a Problem for IP Cameras?

Darren Loher — Wed, 01 Apr 2009 17:36:14 -0000

I'd say the sweet spot for storage costs is in the 500GB to 2TB range of 3.5" hard disk drives. Using a different medium or going to higher scales than that, storage costs go up significantly. Flash and SSD based storage is FAR more than 3.5" hard disk drives. Going to sizes larger than about 2TB drives the need for redundancy requiring RAID controllers, backplanes and other components that can double the cost of the storage, or more.

It's not that storage becomes unafforable at those levels obviously. It's just that it's more expensive than the "sweet spot" of the commodity storage market.

The closer you move your storage to the camera, the lower your bandwidth cost and the smaller unit of storage you need. If one can construct a system that maximizes the use of the sweet spot of storage, you can really lower the overall equipment cost. At the moment, I think the puts the sweet spot in 4-32 channel DVR/NVR units.

Regarding network costs, you're right on with the WAN. It's amazing how many locations still run with only 128-256Kbps of uplink capacity. Upgrading those connections is a very serious, recurring cost when you have a number of remote locations.

For local area networks, it seems that small and medium sized camera counts (4-32) without too much megapixel should be able to handled on most existing Ethernet LANs. (Thinking of staying under 100Mbps aggregate going onto a not already overloaded LAN)

But if you go over 100Mbps, I'd say one is likely going to start looking at the network.

If you want high security between your NVR and IP cameras though, almost all systems I've seen require a separate LAN network infrastructure. Analog starts to look very inexpensive when faced with this. In fact, I'm coming more and more to the conclusion that the "real driver" for IP cameras is Megapixel.

Re: Should You Use Encoders?

Darren Loher — Wed, 18 Mar 2009 17:02:43 -0000

Agreed, but only if you can attach external storage to your existing DVR's, and that is often not possible with 3-5+ year old DVR's.

(ie: the scenario where you've already got DVR's and you want to expand storage)

Re: Should You Use Encoders?

Darren Loher — Wed, 18 Mar 2009 15:15:52 -0000

I think CameraMan has hit the nail on the head!

The most important reason customers use encoders is they need to store a whole lot more video at higher quality than they previously needed.

I would further guess that encoders are chosen because they are a more cost effective alternative to expanding the storage for their DVR's. Too many DVR vendors
1. Overcharge for upgrading storage
2. The DVR isn't upgradable

I absolutely agree that encoders are not an "ideal" architecture, but in light expanded storage being a big driver, I can see how encoders are a very sensible solution.

Re: Why DVR Appliances Are Making a Comeback

Darren Loher — Fri, 06 Feb 2009 18:09:34 -0000

Randy,

What do you think about John's comment that Hybrid and Managed DVR's are a threat in the future? Any comments on Managed Video?

Re: Why DVR Appliances Are Making a Comeback

Darren Loher — Fri, 06 Feb 2009 16:53:48 -0000

In the telecom engineering world, we often focused on having inexpensive, robust devices out at the edge of the network which could be 100% remotely and managed using automated processes. All the edge devices must have a very consistent and methodical way of being configured and managed in order to scale up to server millions of customers.

In the managed video world, those inexpensive edge devices are DVR appliances. For the central control we made our own Envysion Video service for our market niche. But Milestone, ipConfigure or others might also be appropriate for managing lots of remote DVR appliances. We also had to make our own DVR appliance to meet our needs, but it'd be great if we could buy them from 3-5 vendors instead. Maybe someday.