jameslou

Hikvision DS-4016HCI + NovoSun CyeWeb 16 channels edition = very high quality system in very low price, and satisfy your requirements.

Try NovoSun CyeWeb. It has very good support to HikVision compression card.

You can try NovoSun CyeWeb. It supports Samsung SNC-550 and saves video into standard ASF file in Mpeg4 or M-JPEG without transcoding. You can then open the ASF file with VLC player or NovoSun's standalone player.

Try NovoSun CyeWeb, it supports channel grouping. You can setup 4 groups, with each group to connect to 4 cameras and attach to a dedicated monitor.

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.

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.

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.

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.

Try NovoSun CyeWeb at http://www.novosun.com

Use HikVision Mega-pixels IP camera (resolution up to 1600x1200 with pretty good quality). They are selling about USD 300/ each. And the newly released CyeWeb (at http://www.novosun.com) supports that camera with very smooth decoding (real-time decode the 12 cameras is of no problem with a regular PC today). The total cost could be around just $5 ~ 6K.

DirectShow based capture card are generally compatible with vista (but some of them are not stable). For a cheap one you can purchase provideo's which we've just tested to be stable. There may be cards even cheaper. As I know HikVision's compression cards are not vista compatible. They still do not have publicly released vista driver for their cards.

Use 8 IP cam < $90 (such as Panasonic bl-c1a) and NovoSun CyeWeb 8000 ($89.95). You can build a good system < $800. If you have more budget, you can use HikVision IP camera which quailty is quite good and cheap (about $140 each).

NovoSun CyeWeb is new but does very good job on IP surveillance with analystics functions. It also has a free version for simple scenarios.

Hi, Please have try on CyeWeb at http://www.novosun.com. It supports HikVision compression card. Please contact me for a free extension module.

NovoSun CyeWeb http://www.novosun.com