Jump to content

Recommended Posts

Hi Everyone,

Is there any FREE NVR/DVR software which can support multiple IP cameras ( IP cameras from different manufacturer)

Thank

 

Hawk

Share this post


Link to post
Share on other sites

basically there isn't exactly what you ask for...but if you don't mind delving into Linux, then ZoneMinder might work for you...

 

http://www.zoneminder.com/

 

low cost ones that might interest you are:

 

blue iris

cyeweb by novosun

 

a reasonably priced one, that I've used and works well is Visec

Share this post


Link to post
Share on other sites

Free S/w s are not available since it cost to develope them.....but trial versions are definitly available on net.. you can use them for 30 days!!

 

then again you have to install in another PC...

Share this post


Link to post
Share on other sites

Is there anybody can send a 30days trial version to me? here NUUO website has been shield, we can not visit it!

 

We want to try if our IP Camera can working on it! Thanks!

Share this post


Link to post
Share on other sites
5 min. pls...

let me download and check ..if i can attach the zip file...it is 45 MB

 

Kalpesh

 

India

 

Kalpesh,

 

Thanks for your help, I tried but it failed, cause the NUUO software need choose camera brand name and model number.

 

That mean, we should pay for NUUO, then they just can add our IP camera list on it! So disappointed with that! That just can say business just business.

 

My clients in Europe told me that they always use NUUO for Hybird system, so our IP camera lost the market.

 

Nest step, we should talk with NUUO for this issue. Have no ideal how much we should pay for them.

Share this post


Link to post
Share on other sites

Hi,

Good morning!!

 

NUUO support major brands with there major models...

 

I don't think they will charge you for adding your camera in there list!!

 

Only you have to share your API with them...and your system should have that much share in the market!!

 

If that Europion customer has a global precence ; you can approch NUUO that way also...

 

certainly it's a bussiness deal....you have to directly spk. to them...

 

and should commit certain bussinesss terms and all...

 

i m don't aware of much about this comercials since i m into technical part only at my organisation..

 

good luck!!

 

Kalpesh Nikumbh

 

India

Share this post


Link to post
Share on other sites
5 min. pls...

let me download and check ..if i can attach the zip file...it is 45 MB

 

Kalpesh

 

India

 

Kalpesh,

 

Thanks for your help, I tried but it failed, cause the NUUO software need choose camera brand name and model number.

 

That mean, we should pay for NUUO, then they just can add our IP camera list on it! So disappointed with that! That just can say business just business.

 

My clients in Europe told me that they always use NUUO for Hybird system, so our IP camera lost the market.

 

Nest step, we should talk with NUUO for this issue. Have no ideal how much we should pay for them.

 

I don't know of any company that would charge to add support for a camera. At the same time that doesn't mean they are going to jump for joy at you approaching them with an SDK. Development time is not cheap and throwing more developers at a project does not make it go faster. As such development time is one thing they won't be willing to waste. There are a couple of factors in play:

 

1. Do their customers want to buy your cameras? If the answer is no, then don't bother. If it won't make them any money they won't be interested.

2. How hard does your SDK make it to integrate? If you have a ****ty activeX control that needs a wrapper written for it then it's going to take longer.

3. Your country of origin plays a factor. Dealing with manufacturers in China always adds a layer of risks from poor quality control to the fear of stolen code in the SDK.

Share this post


Link to post
Share on other sites

Yes!!

Considering all these facts ( mentioned in detail by thomas ) ....

I write my Suggestion to directly Contact NUUO ...if NUUO is the only option left behind!!!

 

About China Market ..yes! it's alwyas a risk factor........

In india , our market is most influenced with China product just because o f the cheepest product with all decto featurs of famous brand!!!

 

I am even surprise to find so many New brands people talk about on this forum

 

Yes...lead time of such development is around 1 day to some 2-3 months!!!

 

I remeber we have done one small AXIS camera integration with our access software in 1 days time...

 

But do not disappoint ...JUst do it man...let conditions decide the success!!!

 

Kalpesh Nikumbh

 

India

Share this post


Link to post
Share on other sites
Yes!!

Considering all these facts ( mentioned in detail by thomas ) ....

I write my Suggestion to directly Contact NUUO ...if NUUO is the only option left behind!!!

 

About China Market ..yes! it's alwyas a risk factor........

In india , our market is most influenced with China product just because o f the cheepest product with all decto featurs of famous brand!!!

 

I am even surprise to find so many New brands people talk about on this forum

 

Yes...lead time of such development is around 1 day to some 2-3 months!!!

 

I remeber we have done one small AXIS camera integration with our access software in 1 days time...

 

But do not disappoint ...JUst do it man...let conditions decide the success!!!

 

Kalpesh Nikumbh

 

India

 

Axis is an exception rather then a rule. They make it painfully easy to pull the basic video stream from their software. When you start talking about more painful things like integrating proprietary software from the camera....development time goes up.

Share this post


Link to post
Share on other sites
5 min. pls...

let me download and check ..if i can attach the zip file...it is 45 MB

 

Kalpesh

 

India

 

Kalpesh,

 

Thanks for your help, I tried but it failed, cause the NUUO software need choose camera brand name and model number.

 

That mean, we should pay for NUUO, then they just can add our IP camera list on it! So disappointed with that! That just can say business just business.

 

My clients in Europe told me that they always use NUUO for Hybird system, so our IP camera lost the market.

 

Nest step, we should talk with NUUO for this issue. Have no ideal how much we should pay for them.

 

I don't know of any company that would charge to add support for a camera. At the same time that doesn't mean they are going to jump for joy at you approaching them with an SDK. Development time is not cheap and throwing more developers at a project does not make it go faster. As such development time is one thing they won't be willing to waste. There are a couple of factors in play:

 

1. Do their customers want to buy your cameras? If the answer is no, then don't bother. If it won't make them any money they won't be interested.

2. How hard does your SDK make it to integrate? If you have a ****** activeX control that needs a wrapper written for it then it's going to take longer.

3. Your country of origin plays a factor. Dealing with manufacturers in China always adds a layer of risks from poor quality control to the fear of stolen code in the SDK.

 

You are right, Thomas

 

Here situation was very difficult in China, too many people doing this, when I was join this field, just around 3-5 manufacturers, now around 300-400. damm...

 

Here, people just care fast money, if they saw what kind of products has profit, they will join it hundres and hundres. when this field break, can not keep own fast money for them, they will out find any other field.

 

So, that competitive here can not image in your country or other country. If you want keep quality, your cost must be higher, but buyer from global market, they want cheaper things from China, they will inquiry from you or many others, you want business? ok, going down for your price. So I said that just business, they even don't know a good thing should be has little more cost. That situation push us one side keep quality, another side need cut down cost. Really hard work now!

 

And global economy going down so fast, the U.S. Dollar bring us big problem, all our price still doing with USD, also customer can not accept Euro. Every month we lost around USD1000 for money change.

Share this post


Link to post
Share on other sites
5 min. pls...

let me download and check ..if i can attach the zip file...it is 45 MB

 

Kalpesh

 

India

 

Kalpesh,

 

Thanks for your help, I tried but it failed, cause the NUUO software need choose camera brand name and model number.

 

That mean, we should pay for NUUO, then they just can add our IP camera list on it! So disappointed with that! That just can say business just business.

 

My clients in Europe told me that they always use NUUO for Hybird system, so our IP camera lost the market.

 

Nest step, we should talk with NUUO for this issue. Have no ideal how much we should pay for them.

 

I don't know of any company that would charge to add support for a camera. At the same time that doesn't mean they are going to jump for joy at you approaching them with an SDK. Development time is not cheap and throwing more developers at a project does not make it go faster. As such development time is one thing they won't be willing to waste. There are a couple of factors in play:

 

1. Do their customers want to buy your cameras? If the answer is no, then don't bother. If it won't make them any money they won't be interested.

2. How hard does your SDK make it to integrate? If you have a ****** activeX control that needs a wrapper written for it then it's going to take longer.

3. Your country of origin plays a factor. Dealing with manufacturers in China always adds a layer of risks from poor quality control to the fear of stolen code in the SDK.

 

I very much agree! There is no point to integrate a camera that is no one to use, unless the integration needs just couple hours (such as Http/rtsp at standard h.264/mpeg4/mjpeg). ActiveX with proprietary codec is the most difficult situation and we always want to avoid. Some SDK are not even complete. As you approach the middle, you eventually find that with the decent SDK the integration is impossible.

 

My comments to the camera company are, (1) your codec should always compliant to ISO standard, (2) support standard protocol, such as rtp or Http to stream data. (3) For advance feature, provide a pure c library.

Share this post


Link to post
Share on other sites

Ya!!

 

Thus ...how so ever these guys says they have open platform and all........

 

everything happens with business prospectives!!!

 

There is no std.s followed universally....

everybody want there system properitory...so that next business should come to them only!!

 

Have any heard about any such Standerdisation ??

 

Regards,

 

Kalpesh Nikumbh

India

Share this post


Link to post
Share on other sites
Ya!!

 

Thus ...how so ever these guys says they have open platform and all........

 

everything happens with business prospectives!!!

 

There is no std.s followed universally....

everybody want there system properitory...so that next business should come to them only!!

 

Have any heard about any such Standerdisation ??

 

Regards,

 

Kalpesh Nikumbh

India

 

There are already well defined standards for IP camera streaming: http/rtsp, H.264/mpeg4/vc-1/mjpeg.

But there are companies using variance. Unless many people use their cameras, these are the last we want to integrate.

Share this post


Link to post
Share on other sites
Ya!!

 

Thus ...how so ever these guys says they have open platform and all........

 

everything happens with business prospectives!!!

 

There is no std.s followed universally....

everybody want there system properitory...so that next business should come to them only!!

 

Have any heard about any such Standerdisation ??

 

Regards,

 

Kalpesh Nikumbh

India

 

There are already well defined standards for IP camera streaming: http/rtsp, H.264/mpeg4/vc-1/mjpeg.

But there are companies using variance. Unless many people use their cameras, these are the last we want to integrate.

 

Standardizing the stream type is not the same thing as standardized connections given that almost all of the SDK's have a different API for actually getting to the camera's stream.

 

Simply building on existing standards does not mean that you have standardization. And even then MPEG-4 is a standard that is all over the place and different decoders work differently with different encoders.

Share this post


Link to post
Share on other sites
Ya!!

 

Thus ...how so ever these guys says they have open platform and all........

 

everything happens with business prospectives!!!

 

There is no std.s followed universally....

everybody want there system properitory...so that next business should come to them only!!

 

Have any heard about any such Standerdisation ??

 

Regards,

 

Kalpesh Nikumbh

India

 

There are already well defined standards for IP camera streaming: http/rtsp, H.264/mpeg4/vc-1/mjpeg.

But there are companies using variance. Unless many people use their cameras, these are the last we want to integrate.

 

Standardizing the stream type is not the same thing as standardized connections given that almost all of the SDK's have a different API for actually getting to the camera's stream.

 

Simply building on existing standards does not mean that you have standardization. And even then MPEG-4 is a standard that is all over the place and different decoders work differently with different encoders.

 

That's not correct.

 

There should be just a few variance of Mpeg4: Mpeg4 SP, Mpeg ASP, Mpeg AVC (H.264).

The RFC documents have clearly defined the format. If the Mpeg4 encoder follows the RFC, any Mpeg4 decoder (also compliant to the standard) should be able to decode what the encoder encode.

 

RTP is a kind of connection standardization. Don't you see you can connect Axis camera in Quicktime via rstp://.... ? That's because Axis camera following both the RTP and Mpeg4 standard!

 

For other controls, such as PTZ or Alarm output, the camera manufacturer should use Http, which is quite common. And because it is common, many software vendors already have components ready for the Http request. So this is the way of lowest cost to integrate these additional features.

 

For the camera company, if the camera follows the above standards or rules, some companies, like us, can integrate the camera within an hour.

 

The last benefit is platform independent, because there is no need to use the manufacturer's platform dependent libraries.

Share this post


Link to post
Share on other sites

That's not correct.

 

There should be just a few variance of Mpeg4: Mpeg4 SP, Mpeg ASP, Mpeg AVC (H.264).

The RFC documents have clearly defined the format. If the Mpeg4 encoder follows the RFC, any Mpeg4 decoder (also compliant to the standard) should be able to decode what the encoder encode.

 

RTP is a kind of connection standardization. Don't you see you can connect Axis camera in Quicktime via rstp://.... ? That's because Axis camera following both the RTP and Mpeg4 standard!

 

For other controls, such as PTZ or Alarm output, the camera manufacturer should use Http, which is quite common. And because it is common, many software vendors already have components ready for the Http request. So this is the way of lowest cost to integrate these additional features.

 

For the camera company, if the camera follows the above standards or rules, some companies, like us, can integrate the camera within an hour.

 

The last benefit is platform independent, because there is no need to use the manufacturer's platform dependent libraries.

 

First, MPEG-4 isn't defined in an RFC. It's an ISO standard and the definitions of it are in the ISO guidelines. There are RFCs for streaming it. About a half dozen depending on how you want to do it and what you're optimizing for.

 

Second there are currently 20 standards with 3 more in working groups. For instance h.264 is MPEG-4 part 10. This doesn't begin to start counting variations of MPEG-4 like WMV or Dvix which share a lot of base technologies.

 

And this doesn't begin to take into account the use of external plug ins like Active-X controls, all of which require some way to extract the video into a usable format.

 

But hey, Axis uses RTP, a poor and ****ty spec that creates nightmares for firewalls, so that must mean the whole IP camera industry is using open standards, right? Full of ****. There is no open standard used by the IP camera industry that allows the end user to make plug and play use of the camera.

 

You even admit that it would take a software developer time to code for your specific product. That doesn't indicate an a consistent standard among IP cameras.

 

Don't something on top of another widely used standard doesn't make what you do a consistently industry standard. If it did, there wouldn't be a requirement to have development time.

Share this post


Link to post
Share on other sites

That's not correct.

 

There should be just a few variance of Mpeg4: Mpeg4 SP, Mpeg ASP, Mpeg AVC (H.264).

The RFC documents have clearly defined the format. If the Mpeg4 encoder follows the RFC, any Mpeg4 decoder (also compliant to the standard) should be able to decode what the encoder encode.

 

RTP is a kind of connection standardization. Don't you see you can connect Axis camera in Quicktime via rstp://.... ? That's because Axis camera following both the RTP and Mpeg4 standard!

 

For other controls, such as PTZ or Alarm output, the camera manufacturer should use Http, which is quite common. And because it is common, many software vendors already have components ready for the Http request. So this is the way of lowest cost to integrate these additional features.

 

For the camera company, if the camera follows the above standards or rules, some companies, like us, can integrate the camera within an hour.

 

The last benefit is platform independent, because there is no need to use the manufacturer's platform dependent libraries.

 

First, MPEG-4 isn't defined in an RFC. It's an ISO standard and the definitions of it are in the ISO guidelines. There are RFCs for streaming it. About a half dozen depending on how you want to do it and what you're optimizing for.

 

Second there are currently 20 standards with 3 more in working groups. For instance h.264 is MPEG-4 part 10. This doesn't begin to start counting variations of MPEG-4 like WMV or Dvix which share a lot of base technologies.

 

And this doesn't begin to take into account the use of external plug ins like Active-X controls, all of which require some way to extract the video into a usable format.

 

But hey, Axis uses RTP, a poor and ****** spec that creates nightmares for firewalls, so that must mean the whole IP camera industry is using open standards, right? Full of ****. There is no open standard used by the IP camera industry that allows the end user to make plug and play use of the camera.

 

You even admit that it would take a software developer time to code for your specific product. That doesn't indicate an a consistent standard among IP cameras.

 

Don't something on top of another widely used standard doesn't make what you do a consistently industry standard. If it did, there wouldn't be a requirement to have development time.

 

Yes, Mpeg4 is defined in ISO. My mistake when typing.

 

And of course, there are many variances that don't compliant to the ISO standards. But the 3 mpeg4 variances I just listed are all ISO variances, they are standards.

 

I never say those are already IP camera standards. And the fact is exactly opposite. The problem is whether the standard exist or not? It does exist. Just many companies do not follow.

 

What I mean is, if the camera generate stream that is compliant to the standard, the integration will be much easy, and third-party software vendor will have more motivation to integrate it, no matter what the country of origin is. That's my comments for new camera companies.

 

Moreover, a camera follow the standards doesn't mean it cannot provide additional features. It can still have its own connection type or propertied format, but developer should have the option. And with the standard there can be a fast first phrase integration.

 

I don't agree that the we should spent too much time on integrating the camera for different connection types or propertied codecs. If we can save the time, we can do many others.

Share this post


Link to post
Share on other sites

Yes, Mpeg4 is defined in ISO. My mistake when typing.

 

And of course, there are many variances that don't compliant to the ISO standards. But the 3 mpeg4 variances I just listed are all ISO variances, they are standards.

 

I never say those are already IP camera standards. And the fact is exactly opposite. The problem is whether the standard exist or not? It does exist. Just many companies do not follow.

 

What I mean is, if the camera generate stream that is compliant to the standard, the integration will be much easy, and third-party software vendor will have more motivation to integrate it, no matter what the country of origin is. That's my comments for new camera companies.

 

Moreover, a camera follow the standards doesn't mean it cannot provide additional features. It can still have its own connection type or propertied format, but developer should have the option. And with the standard there can be a fast first phrase integration.

 

I don't agree that the we should spent too much time on integrating the camera for different connection types or propertied codecs. If we can save the time, we can do many others.

 

Except that even following a number of standards doesn't necessarily mean that intergration of a product is trivial. I'll cite MPEG-4 again. The following manufactures are all large players in the industry:

 

1. Axis

2. Sony

3. Panasonic

4. Toshiba.

 

All of the above use a standard web server platform streaming MPEG-4. Not one of them is compatible from an API standard. All of them require completely different solutions to allow capture of the MPEG-4 stream. These different solutions are not a matter of hours to implement but a matter of days or weeks depending on what structure you already have. In all cases, all of the above manufactures follow the standards completely and to the letter.

 

To say that standards exist and that companies don't use them and it's their fault is silly. All of the manufacturers above followed standards. But because there are no common API to detail a common set of standards to be used in the industry you end up with no interoperability among cameras.

 

When ever you imply that there are a set of standards used by the IP camera industry to allow for interoperability, you are confusing the end user and the installer. Simply building on existing standards or even having a common pool of standards does not instantly create interoperability.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×