How Do I Develop My Own Embedded NVR?

I want to design a standalone NVR. I know exactly what I want but I simply dont know how to materialize it due to lack of programming knowledge. I plan on having this designed in house and then having China manufacturer the boards.

What kind of people do I need to hire to make this happen. Do I need people that are well versed in specific video surveillance programming knowledge. Or can any Linux programming expert find a way to create this? Next, what are the hurdles to create the boards, do I need engineers for this or can I outsource this to some company in China?

Lets get past the "your way out of your league" comments and cut to the chase. Im looking for generalized ideas.


The hardware part strikes me as easy, in the sense that many outfits can build customized hardware for you, and do this all the time.

The harder part strikes me as the software side. Are you looking for something to develop the software from scratch or take an existing recording application and customize it for you?

Great question. Scratch really. Although I wouldnt be opposed to starting off and working with an NVR supplier who will give us full access to modify their current GUI's and web interfaces completely. Atleast this would give us a base in which we could work off of. But ultimately scratch would be ideal and build it from the ground up.

Do I need people that are well versed in specific video surveillance programming knowledge. Or can any Linux programming expert find a way to create this?

Yes to the first. No to the second.

Embedded linux is an art within an art.

In some ways using Linux, all flavors, has gotten easier over the years, as so many things have been added to the open-source catalog that are ready and free to use.

Things like DD-WRT, openRTSP, ffmpeg, VLC, busybox, lighttpd. Google any/all of to those to get an idea.

But Linux has also gotten far more complex in some ways too; take Ubuntu, a very popular distro of Linux. Although it's easy to install the base, once you start adding packages of goodies in the mix, you bound to run into all sorts of compilation and linking errors.

You think some Windows errors look nasty? Wait to you see the output from a kernel build that runs for an hours with literally thousands of dependencies, scrolling down your screen before saying something cryptic like "error: -q not supported".

If you could use Ubuntu though it would still be great though compared to what goes hand in hand with Embedded Linux. The dreaded cross-compile, which because of the size of the target machine environment, is a necessary but evil compromise in where you build a kernel to build another kernel. Then you write code in one environment but compile it for another target, usually some MIPS or other tiny processor that has limited resources.

In short you need a Linux networking expert and an embedded Linux expert, and a RTSP/ONVIF expert minimum. Could be the same person, but it gets real hard to find...

I could say a lot more but, it would be better for you to indicate what you already know about the target environment and how much you are developing something from scratch as opposed to cobbling together a system from the available GPL catalog.

This is a new open source NVR application hosted on Github that appears to run on Linux. We've been meaning to contact him. It looks like a sole developer in China. You might want to start with that or hire him.

Undisclosed 2, I am sure we will have your detailed review of this shortly....

sweet!

Thank you for sharing! I was looking for something like this a couple years ago. Not that I have any reason to be but I just knew someone had to have written an open source recorder.

David, a few years ago, this one did not exist :)

If any tries it out, let us know. It is on our list of things to take a look at. Ethan found it recently.

This app is a perfect example of what you in for. It looks (and probably is) great!

To build this you would only need a "regular" Linux expert. You might not need even to build it for Windows, since there are usually binaries available already for major platforms.

But to turn this into a running app on an embedded Linux platform will require an embedded guru, unless it's been done before, for your target. The main problem is that a lot of these libraries are HUGE in embedded systems terms. You need to cut out most everything that your NVR doesn't need to have, while keeping what you do.

When you say embedded Linux, I assume you mean "not a PC".

What's your target hardware architecture? ARM or MIPS or Cris or? If you tell me what you're targeting, I can see what ports might be available...

Bottom line is, someone who unaware of cross-compilers and cross-arch toolchains is going to have a steep learning curve before being able just to "try it out".

GitHub should not be confused with the App Store...

On the hardware side, there are many contract manufacturers in China that can help with this. But to do it well you will need somebody probably on the ground in China who can liaison with the CM and make sure you get what you need at the price/quality you want. There are a thousand details to be taken care of, even if you’re buying a box they already pretty much make. If it’s your own general design, there are a thousand more details.. That being said they can/will do amazing things. We wanted a new motherboard with certain components located physically at certain positions on the board—no problem, our CM designs and builds a motherboard for us to our spec, quickly, and inexpensively. Crazy.

Like John said (and with good comments from Undisclosed 2) the software is going to be the busy part:

First off do you really mean an ‘embedded’ system? An embedded system is something like a wifi router or a set-top TV box (or an IP video camera). These are appliances with a very specially constructed OS/software that is designed to be highly durable, and requires next to zero administration/maintenance. There is no console to speak of where user/administrators service the box. It has to run all the time even when it’s power cycled and always be on. It needs to never fail during a software update, etc.

Compare that to an appliance type box that simply runs a server OS/software. This is a different beast in that the server-type OS/software can and will require configuration and maintenance (such as the application of software updates, repairing a filesystem, installing a device driver, etc). The assumption is an admin can login to Windows or a linux command line and configure or fix stuff up when necessary. This is a less specialized type of OS configuration/architecture, but is higher touch in terms of maintenance and support.

Once you figure out your platforms (hardware and software), you can think about the actual NVR software application(s) you’ll run on them. If you survey 20 NVR systems you’ll find that maybe 80-90% of their functionality is overlap. So it would be a shame if you spent your time and money developing the ‘me too’ features. Other parts of this thread pointing to open source or reference design type software are worth considering. This is also where you need most of your video and more specifically IP video surveillance expertise in-house. They’re going to need to know a good bit about encoding, decoding, how to talk to cameras, how to talk to clients, etc.

Good luck.

Over 12 years ago I stumbled across ZoneMinder, written by a British programmer for his own amusement, and it's entirely written for Linux, and uses the LAMP environment. I was amazed then of the features he developed, and I wish my favorite VMS had one of the more interesting features (more later), and perhaps yours needs it too. The documentation is great, and if I were to create by own "A-BOX" this is where I would start..... http://www.zoneminder.com

There are a number of great supporters that have developed LIVECD's, and tech guides. It's really a great product. It would be a terrific platform for the right integrator to begin building an MSP video business... "Don't sell anything but the cameras", retain ownership of the hardware, the software, provide maintenance and support... for a flat fee....

As for the feature it had, that remains rare, is the ability to make a Motion Alarm Area (green pixel overlays), while in the same view, create an alarm area (red pixel overlays). What VMS has this today, and who had it 12 years ago?

Thanks for the suggestions.

What I mean by embedded is a want the device to run without a hard drive. OS will be built into the motherboard. Basically, not PC based. Just like a Hikvision NVR basically.

Im gonna take a look at that open source thing.

Where would I look to find a qualified linux expert to do this? How would the job posting read? Basically, how would I even market this type of job. I just got alot of ideas but have no programming experience whatsoever and I need to explain my ideas to a person who is able to materialize them. One thing Im concernced about is people that are experienced in specific surveillance programming are not exactly easy to come by and plentiful. Thats why I was hoping I could find a more general experience linux person who could "muddle" (for lack of better terms) his way into getting a GUI put together.

In other words, what would be a good starting point?

What I mean by embedded is a want the device to run without a hard drive.

You mean boot without a hard drive, right? Because you'll actually need a hard drive to record anything, no?

So most of the OS will be directly in the firmware, with a limited amount of flash storage for configuration persistence. That's pretty standard.

Start with one of the few open source projects. Ask the lead developer of those projects if he can consult. If he cannot, ask if he knows anyone who can.

Listen, you have to build upon an existing project. Otherwise, you are talking years and probably million dollars plus to build anything that would even be remotely competitive.

Great point, I will branch off from there and see where it leads me.

You should *really* buy a few similar devices and do a basic teardown of them and spend some more time getting familiar with exactly what you want.

I know you don't want to hear the "you're out of your league" comments, but I've seen variations of this same situation end badly lots of times. In order to find and hire and manage the right person you at least need to have a functional understanding of what is practical and a solid concept of what the project should cost, etc.

Without the above you run an insanely high risk of hiring someone who is either vastly unqualified (though they would lead you to believe they can pull it off), or you'll find someone who IS qualified but ends up resenting that they are doing all the work while you are bumbling through making this happen.

I would suggest starting with this:

1) Put aside the whole form-factor part right now because you're going to be developing the first rev on a common PC base because that is the cheapest and most readily available platform to get started on. Once you have a functioning prototype you can determine resource needs and find the right hardware and port your project to that platform.

2) Write out a list of all the core features/functions you want. This is the product requirements doc (PRD), it should be formatted logically and cover all the core functions (finding cameras on the network, connecting to cameras, configuring cameras, streaming/recording video, displaying live video, accessing recorded video). Sometimes it helps to write a marketing spec sheet first and work backwards from there. Design the product brochure that highlights your compelling features and work backwards to what things need to exist in the product to make that brochure "real"

3) Throw a dart and pick a linux distro, it doesn't really matter yet but I'd probably use a standard Debian platform. Take your PRD and break it down to the most simplistic functions. For now throw away things like "play back video at 5x speed" or "video should be accessible with any browser or mobile device". This will look something like "Add camera by IP address (no need for auto-discover yet), stream/record video until hard drive is full (we'll worry about overwriting oldest video later), view live video from 1 camera, access recorded video (this might be just from the user manually entering a date/time, no fancy sliders or thumbnails yet).

4) Take the above and put up a job on elance.com or similar "rent a hacker" site. List out your basic specs from #3 above as the job requirements "Create software packages to run on Debian that can do x, y, z". Make sure you also mention that all source code should be commented, package dependenices clearly listed, and so on. Search for some other elance jobs and read them to get an idea of what to ask for.

5) Take the top 3 responses and hire each of them idependantly. You'll probably end up paying somewhere around $1000-$2500 in total for this.

6) Evaluate what you get back. At this point, if you haven't already, you'll start to realize how poorly defined your spec is/was and how hard it is to effectively manage programmers. I don't mean this as a jab at all. Here you'll have (hopefully) 3 semi-working variants of what you asked for. You'll start to see where you could have made things more clear, you'll see how different people implemented the same thing in unqiue ways and you'll hopefully get some ideas about which options seem most efficient, etc.

You're not going to go from zero to product on something like this without a lot of interim steps, and a lot of time and money invested. At this stage you're at the "you don't know what you don't know" phase and the best way to get over that is to not worry about all the minor things and just dive in and start tinkering. You're probably 6 months at least from really being able to hire the "right" person, so don't worry about using some contractors for now as essentially day laborers to start putting some of your ideas into motion.

After you've got a better grip on things, I'd personally start looking for a UI/UX person before I was hiring a fulltime programmer. The under-the-hood development part of this is pretty straight-forward, you're not inventing much there, you're just tying a lot of known concepts together. Yes, not just any person can do this, but you don't need a super-niche person either. What's going to make or break a product like this, IMO, is the user interface. Once you decide what it should/shouldn't do, you need to think about how you elegantly present all those options to the user in a clean and intuitive interface. I will tell you from experience that 99% of programmers will completely suck at this, and if you don't design the UI/UX up front you're going to end up with something that technically works, but in a very messy manner.

Amazing advice. I appreciate the well thought out response. Seems like you have experience doing the same thing?

I've spent the majority of the last 15 years or so working with various tech startups getting things off the ground.

From a job posted recently by a Non-American North American provider of end-to-end solutions:

This is a good start for candidates.

I tried this many years ago in the early years of VoIP, and hired a terrific linux core developer, and planned to make a VoIP PBX. We deployed the first in 2006, and within a year, I realized my company is better at Sales and Support, and not engineering, so we scrapped the development, and moved our sales effort to a commercial platform.

Undisclosed 1, IMHO, you need to decide what your hardware architecture, i.e., processor is going to be before you hire your guru.

Do you have any requirements, price, footprint, power consumption, that you can share at this point?

Btw, there is a lot less than meets the eye to a Hikvision NVR.

Pretty sure it can't run any distro of Linux, or even most. Choose wisely. Ubuntu is a gorgeous hog, good for developers desktops or if your are targeting x86. But x86 is much more expensive.

Take a good look at busybox and buildroot for your target environment. They are proven technologies in which many of the devices you use today employ.

Yes, a skilled developer working off of a tighly defined PRD/MRD would jump right to busybox, and likely also have a target processor and reference platform in mind. The downside to those platforms in the early early dev stage is that they are so stripped down. Everything you do typically needs to be customized, extra packages installed, etc. You can spend a lot of time hunting down dependencies and debugging, only to find out in the end that your idea of using OpenRTSP as your recorder base won't work anyway. For projects like this in the past we've usually started with a more generic distro, done some prototyping, and then determine what can be stripped off later.

OP here lacks the background/experience to have that part of the product fully defined. Realistically at this point I don't think it's fully known what kind of resources this device needs. Will it need to support 4 channels? 8? 24? Will it need to support higher-res (4K+) cameras, or is it targeted at a lower-end market? Support a local console only, or network clients as well?

Getting a couple of prototype implementations built will make it easier to start to figure things out, especially as you have conversations with potential dev leads "Here is a rough working abtract, but I need this to run on a $25 hardware BOM", or "Here is the concept idea, but I want this to run on this ruggedized platform I found that is optimized for my target market of school bus autocross".

I've seen skilled developers have to go through some very serious machinations to get code to run on a hardware platform that was thrust upon them for various reasons. That is expensive and time-consuming, and I'm guessing OP doesn't have the deep pockets required to really go that route.

Just so you know I agree with pretty much everything you've said technically and you obviously know what you are talking about. :)

I just think we differ in what we think the OP is trying to do ultimately. For instance, this

You can spend a lot of time hunting down dependencies and debugging, only to find out in the end that your idea of using OpenRTSP as your recorder base won't work anyway.

is very true. But also very common is to develop something under a full Linux distro, telling yourself that you will leave the target selection until later, after doing some prototyping etc.

That can become hard enough and it's easy to fool yourself and think that you will just 'port' the product to ARM or MIPS at the end. That's when you find that libc is the size of Vermont and those nice crypt libraries or even curl, blow you out of the water.

Since OP is not coding himself, I'm recommending that who ever he hires as his guru be an embedded guru as well. For ease of development, you would develop under Debian etc, but always maintaining a cross-compiled target binary.

Of course as you point out, OP may have a hard time determining what the target arch. will be, until he gets his hands around the functionality and cost issues.

The best shortcut to this is to find a device on the market with similar cost and complexity, if not functionality, and hack into it and find what is being used...

Also the lengthy open source GNU riders that come with these products are an excellent source of what's going on 'under the covers'.

IMHO.

Good points...

The bottom line is that a project like this is REALLY hard for someone to undertake if they don't have a basic grasp on all the underlying details that make or break something.

It's kind of an odd tradeoff between time, luck, money and basic embedded hardware startup knowledge.

If OP is really lucky, he might find just the right person that can bring this all together nicely. Or he might find a pretty decent hacker and stumble on a good Chinese OEM that can build an over-resourced box cost effectively enough to get a profitable V1 unit out the door.

It's funny you mentioned the GNU riders. I was debating if I should even mention the fact that you might have to watch out for certain open-source projects that would more or less limit your usage in a commercial project. You could build a very workable prototype and then find out some library or project you used isn't commercial friendly. It's rare, but it's also another thing to be on the watch for.

People don't often realize the minefield you navigate in bringing something to market. We haven't even gone into the $200K+ you could easily drop if the hardware is not something that is already FCC/UL/etc. listed and you have to submit it for testing on your own dime.

All in, my estimate is that this is a $1MM USD venture at a bare minimum. That's money invested before you make your first dollar back, and that's based on either a generous heaping of knowledge or luck.

You could build a very workable prototype and then find out some library or project you used isn't commercial friendly.

Yes, I believe this is why VLC was pulled from the App Store for several months; a claimed violation of terms by some author. Can happen for sure. Hardware too; remember Buffalo used to make home wifi routers, then one day no more, because of some unexpected patent ruling.

Here's what I think. Undisclosed might have a shot at a sub $500,000 alpha model if he hooks up with the right people and takes every idea he legally can from existing hardware.

But he has an idea to do at least something differently, otherwise what's the point? Depending what *that* is, it could take him double or triple that easily.

I'd ask him what it is he's trying to do, but of course that's his rightful secret.

I'tl be interesting times, no doubt. :)

I have been developing embedded NVR for many years and the trend, like mobile phones, SOC integrate more and more logics and the price drop dramatically. The difference between NVR and smart phone is there is not big software dominated company like apple or google. If you really wants to create a whole new NVR, software is the key part. Hardware is just find an OEM to follow chip maker's ref design and control the PCBA cost. Good software design decides the future of the product.

Having personally implemented two NVR’s, one for use in large system installations and the other for use in a home security system, I confirm what others to this post have suggested. When your project is completed you’ll look back and see something like a 90/10 split between software and hardware engineering. As for use of open source packages (Live555 for the RTSP protocol support, openCV for analytics, ffmpeg for video processing, et.al.), they can greatly ease the software development effort, assuming the software engineer is familiar with them. If not then get ready to be paying for a lot of training. Oh, and assuming your goal is IP camera support then do look for a software engineer who also has ONVIF experience, or be ready to invest heavily in drivers in support of non-ONVIF legacy IP cameras.

Richard,

Good feedback.

Btw, on the ONVIF side, there are a few libraries / plug-ins available for that. We covered one here - Ready to Go ONVIF 'Kit'

Good point, and certainly worth looking at. I did, but I couldn’t make the cost/value metrics work for my particular project.

Can I ask “Why” you want to develop your own NVR?

Do want to have a NVR with your own name / brand?

Do you feel existing NVR’s don’t have some features that you would like to offer?

Who is your target market for your new NVR? Home, Small Business, Big Business / Enterprise?

Do you have the resources: money and route to market to make this happen?

These questions need to be answered before you can move forward in any of the directions outlined by some of the excellent posts above.

If you can answer these questions you will get better more targeted advice on IPVM. I have worked on developing a PC based DVR from the ground up and believe me you cannot overestimate the time, cost and unforeseen problems ahead. And that is just to get a working unit then you have sell the unit!

On product development in general you will need to get up to speed on the latest methodologies “Lean Product Development”, have a look at The Lean Product Playbook by Dan Olsen or anything by one of the fathers of Lean Product by Steve Bank.

I look forward to your reply to the questions above.

Regards,

Jim

Good feedback. Basically, I dont want to create anything groundbreaking by anymeans but I want a whole line. Most of the NVR's nowadays have everything I need, but are just convoluted and bloated. I want to simplify and dumb down quite a bit of stuff.

As far as what version of linux distro I will be using, I have no clue in the world. I hope my linux experts can answer those questions better than me.

I have decided what I am going to try to do is find a small manufacturer that will allow us to hack into their NVR's and poke around and let us "change" stuff. I dont think this will be hard to find in China. At least this will get our feet wet and will show my linux guy what general coding looks like for an NVR and how to make necessary changes. Eventually we will move on to bigger and better and more original things, but I think this is a good place to start without wasting too much money.