TheUberOverLord

Take your own advice. You are the king of fear mongering. Sorry to have hurt your feelings ("Not"). But NEWS FLASH! there are other choices besides Hikvision or Dahua. Not saying they are bad, but there are other good choices as well. So face the facts. Sometimes that's painful. Making up failure risks without supporting scientific facts from trusted sources won't undo that pain and will only in the end make you look silly. Don

Can't agree more! The truth is much like comparing an older model car or truck you once had years ago to current models. Things change. Maybe the current model is better or worse than the older model you once had. So, one can't claim that any specific IP Camera model now is this or that. If they never owned that IP Camera model now being sold. This is why reading as many reviews in different places from others is so important. Because you do get the comments from others that have actually used that specific model. I find it humerus at best. That some make claims of high failure rate risks. Show me the scientific statistical facts and details provided by a trusted source, to back up that garbage. If you can't do that? Then stop the fear mongering! LOL Don

You implied that is was done in this thread. We have had this discussion MANY times over. I'm not getting into this again. Don't make stuff up. What I stated is clear. Please re-read it if what I stated confuses you! I never stated you made any statement here in this thread, yet. But you have in the past. Here is a recent example. One of many, where in fact you encourage same: viewtopic.php?f=19&t=48590&start=15 So. Try being more honest. As I stated. IMHO your definition of what's trash and what's not, is a very odd one. Which is why I suggested what I have here. Don

Point being, that you have in the past. Even in the recent past. Nobody said you did it here in this forum thread yet! Don

That camera, like the foscam clones is compete trash... Suggesting the purchase of "Grey Market" Hikvision equipment that might not be capable of upgrading and might become incompatible with other Hikvision equipment in the future are really trashy suggestions. Seems like you have a very selective definition of "Trash" which is limited to your limited experience as well! LOL I would read many different reviews, in many different places by others who have purchased the equipment in question. Then based on your budget do what many others say is working for them vs. making a purchase based on any single persons statements alone. Any single person can play pro American football from their couch. Few would survive the first play on the field for a pro team and not end up in the hospital. Better to get many opinions from many people and then read many reviews in many places about their suggested equipment choices. The truth is much like comparing an older model car or truck you once had years ago to current models. Things change. Maybe the current model is better or worse than the older model you once had. So, one can't claim that any specific IP Camera model now is this or that. If they never owned that IP Camera model now being sold. This is why reading as many reviews in different places from others is so important. Because you do get the comments from others that have actually used that specific model. Don

There is a firmware update that fixes this. Make sure your have a US region camera before updating. How can I confirm this? Please see this. It has an explanation by Hikvision: http://overseas.hikvision.com/us/download_89.html Don

You are very welcome. First I would like to say that there really is no perfect bandwidth calculator and some like one over others. I say this for a few reasons. There are many variables involved that vary from maximum possible concurrent users accessing video/audio to all cameras remotely, required/acceptable FPS ("Frame Per Second Rates"), number of "Key Frames" used, bit rates which can/could be fixed or variable and even the use of manufacturer proprietary protocols such as H.264+ as one example supplied by Hikvision that could decrease bandwidth. Because of the above and many other possible variables. It's not a good idea to use bandwidth calculators for anything but rough estimates. Before trying to estimate remote bandwidth usage. It would be best to decide what the average and maximum total concurrent remote assessors will be. Because whatever the bandwidth estimates are you will need to use "Bandwidth * concurrent remote assessors" for live video/audio. It's important to note that if the number of concurrent remote assessors exceeds your ISP "Upload" bandwidth then all other remote users will be impacted. For corporate networks this may be more important than for home networks. If that corporate network supports remote access for other things. Because some overhead can/could be seen more likely than not whereas on many if not most home networks that overhead might no be always seen in all cases. Especially more so if a significant amount of ISP "Upload" bandwidth is already currently in use or needs to be available at all times, for a corporate networks continued stable operations. That said. You may wish to try a few online bandwidth calculators to compare their results: https://www.google.com/?gws_rd=ssl#q=ip+camera+bandwidth+calculator Depending on how the cameras are being accessed remotely. It might not be so easy to restrict or force remote users to access sub-streams only for example. Without also changing the stream being used for access for those on the corporate LAN and even for any recordings. Again, it depends on how the cameras are being accessed remotely. Some examples of the above are that some NVR equipment does not support the simultaneous use of main and sub streams to a camera. Some methods of direct access to cameras don't support the ability to limit specific users to sub stream access only while allowing other users simultaneously to use the main stream for the same camera. I wish I had a better answer. I'd rather not give you a psychic prediction saying all will be fine and always will remain fine. But to instead try to give you an honest answer based on facts and not speculation and conjecture. But there really is not one right answer. It depends on the mix of cameras being accessible remotely, concurrent remote assessors to those cameras as well as each cameras settings being tuned and tweaked for remote access as well. While they can still continue to meet any and all of their other requirements. But bandwidth calculators can still provide very rough estimates. Don

You are very welcome. Here is a speed test which uses HTML5 no Java or Flash that you can run from within your cooperate LAN to determine current bandwidth: http://speedof.me/ Note: Remote access to a camera located on a corporate or home network uses the "Upload" bandwidth not the download bandwidth. Because of that it's the upload bandwidth not the download bandwidth that you need to be concerned about in this case. Don

One of the primary causes of "Motion Blur" is shutter speed. That said, many decent IP Cameras that support 30+ FPS also support higher shutter speeds. Because without higher shutter speeds you can't get 30+ FPS rates without increasing "Motion Blur". That said, a person running, cars and other things moving quickly, may still blur at high shutter speeds. Point being, that in many cases IP Cameras that can do 30+ FPS rates generally will have less motion blur at 30 FPS, than those that have a maximum of 30 FPS. This also assumes that your IP Camera is set to use higher bit rates and that your network and equipment can handle higher bit rates as well. Without introducing and causing other issues, because they can't. Besides getting not much more than "You don't know what you are doing" responses from some responders. Which is their standard response vs. being more helpful with solutions. It can't hurt to do a search here in the Forum. For "Motion Blur". There are some good suggestions that don't include the overhead and insulting tones of "You don't know what you are doing". One Important thing to remember is that as you increase shutter speeds you may require more light especially at night. This is because generally as shutter speeds increase images/video of the same view gets somewhat darker. Depends on the IP Cameras hardware and image sensor as well. Don

I stand by my statements in my post. They are clear and concise. You can re-read my post if required, to try to more accurately understand what I stated. Don

You need to tftp the hik firmware. It's best not to "Kludge" LTS firmware with Hik firmware, at this time. A major firmware release for all Hikvision NVR's/DVR's is currently scheduled for release by the end of this month and another matching release for Hikvision IP Cameras is currently scheduled for the end of November. To make sure that ("non-crippled non-grey-market") Hikvision IP Camera equipment will better support new features across Hikvision product lines. Once these major firmware releases are found to be stable for the Hikvision product lines. OEM's like LTS will have working versions with many if not all of those new fixes, enhancements and features. Like the Hik firmware, but specifically for their OEM product lines. Whatever you do. Please! don't use "Kludged" Hik firmware to downgrade LTS products to older Hik firmware. You may regret doing that, sooner than later. It would be best/better to stay on any most current firmware you have for LTS products at the moment. Because of all this going on. Don

Not sure if living with automatic refreshed real-time snapshots with what I call "Infinite Zoom" ability is acceptable? This Interface will work with any Network DVR/NVR or IP Camera than can provide snapshots using a HTTP/HTTPS URL. You can also display different brands and models at the same time. You can also password protect access with your choice of User Id and Password not related to any other User Id and Password. It's also compatible with all Internet browser capable devices. Which can be using any Operating System or browser and does not required that anything be download to use, including any plugins or media players. You can zoom per camera or all cameras at the same time and un-zoom a camera or all cameras at anytime. The zoom is infinite and on a per click percentage basis. You can set/choose what that percentage is per zoom click. There is no limit on how many cameras can be displayed at the same time. I suggest this because it uses much less bandwidth then multiple IP Cameras using full-motion video would and you are getting a HD image which is simply being initially displayed smaller than the actual image per camera received ("You can set the initial size to display any size you wish and keep the aspect ratio"). You could if you wish. Add a link under each specific camera, to launch full-motion video on a per camera basis or for all cameras. Again, this Interface will and does work from any Internet browser capable devices you use as well. Which is yet another major advantage. It can use HTTP or HTTPS even if your DVR/NVR or IP Cameras don't support HTTPS: Browser (HTTP) <-> Interface <-> IP Camera (HTTP) Browser (HTTP) <-> Interface <-> IP Camera (HTTPS) Browser (HTTPS) <-> Interface <-> IP Camera (HTTPS) Browser (HTTPS) <-> Interface <-> IP Camera (HTTP) Live Examples - Live Real-Time Demos ("Using 5 Foscam IP Cameras for demonstration purposes"): HTTP http://107.170.59.150/foscam/GlobalZoomExample.htm User: admin Password: admin http://107.170.59.150/foscam/GlobalZoomExampleLogin.php HTTPS ("Note: You will see a warning because a self-signed certificate is being used") https://107.170.59.150/foscam/GlobalZoomExample.htm User: admin Password: admin https://107.170.59.150/foscam/GlobalZoomExampleLogin.php The interface is php based and is free. You can see more details and get the download link for the files here: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html#p42139 Note: The above Interface was initially designed for Foscam Network IP Cameras but as stated above. The Interface will and does work with any brand and model of DVR/NVR and IP Camera that can supply snapshots via a HTTP/HTTPS URL. This is why the details above are located at Foscam.us Don

Accurate and true specifications are extremely important to better understand the abilities and limitations of Network IP Camera equipment. So specifications are far from "meaningless". Accurate and true specifications can also allow you to better compare other brands and models of Network IP Camera equipment that is using the same internal hardware. To get a better idea of price ranges offered by other manufacturers, who may also be using similar hardware. It's best to locate many different reviews for specific Network IP Cameras by their brand and specific model numbers. This way you get an idea of what people think that actually purchased them. If you can't locate many different reviews for a specific brand and model of Network IP Camera equipment it's best to continue to look around unless you have the time to wait for real reviews on that specific brand and model. That said. Firmware and future firmware support is highly critical as well. Even if a Network IP Cameras internal SoC ("System on a Chip") and camera sensor are known to be of high quality. If firmware is currently not capable of utilizing all the features that the hardware supports. Then you won't be able to fully appreciate the advantages that hardware could/can support. Unless that manufacturer is committed to providing firmware updates. Last but not least. Don't ("As in ever") knowingly purchase "Gray Market" Network IP Camera equipment. Because there are major firmware enhancements that normally take place over the normal expected lifetime of Network IP Camera equipment. To do so, is purchasing a potentially "Crippled" piece of new Network IP Camera equipment that might not be capable of being upgraded as new firmware releases are released. Don

Please feel free to send me a PM ("Private Message") and I will give you an email address for the Hikvision person who is in charge of this area. So that you can make sure you are truly getting the correct answers to your questions on this subject matter. As well as make any suggestions you may have on this subject matter. Don

I can only suggest creating a relationship with Hikvision as I have done when creating interfaces to their Network IP Camera equipment. Make suggestions as well. That said, I already have had conversations about this subject matter with them. But since others think implementing changes like this are "easy". It should be just as "easy" to make suggestions and also ask if these changes are more complicated then some think they are. I have no doubt what Hikvision's responses will be. Because I've asked the same questions in the past and tried to share their responses here to no avail. Don

I disagree. It would be easy for them to send the motion flag whenever the camera is moved. Please feel free to suggest that to Hikvision and make the claim that you feel it will be "easy to do" while also asking them if they agree. Please post their response back here. Don

I never said anything about implementing motion events. Please read. The users DONT want motion events. All they wants it to trigger recording when the ptz is manually engaged. It is VERY simply and easy to implement this. Extensive coding is NOT needed. To make changes to current PTZ logic will require extensive coding changes. Don

Its not a false positive if you are moving the ptz and want it to record. Even without an on/off option this would add minimal HD storage space unless the ptz is manually operated hours at a time. A simple on/off option would eliminate that issue for constantly used ptz's. The solution is very simple to implement, certainly easier than traditional motion detection...they simply choose not to. If one was NOT continuously recording then one would not have been recording while using PTZ controls. So what you are saying makes no sense. I clearly stated that current PTZ control use currently suspends any motion detection events ("Including recording") and in many cases notifications. To undo that requires extensive coding changes. There is no "easy" fix to avoid those changes at this time. Continuous recording is never suspended as I assume you know. Which is why this currently is the only option to use in many cases when PTZ controls are being used to not miss recording something that could be taking place while using PTZ controls. This is why Hikvision is reviewing how they should make those extensive ("Not simple") changes and when they should suspend motion detection events and notifications. Once that review process is complete, then those extensive coding changes will that place. Which are far from simple. Don

Actually, it's not that simple. If it was it would currently be being done. The facts are false positives create wasted disk space. This is why the current solution has and is to simply use continuous recording since no additional space is required because recording is continuous anyway. This all said. Major coding changes would be required to undo the current PTZ motion detection logic suspension in any case. As stated. Hikvision is looking at doing this at minimum with auto-tracking that invokes PTZ controls during that process. Don

Depending on what motion detection features, events and notifications you had enabled combined with how often you use PTZ controls manually. I think you would be extremely surprised at the amount of false positives you would generate. When not suspending motion detection events and notifications during the manual use of PTZ controls. This is why I can't see most Network IP Camera manufacturers even taking the time to use a checkbox option for not suspending motion detection events and notifications when PTZ controls are invoked manually. I do agree however, that when features like auto-tracking are used which involve the automatic use of PTZ controls that Network IP Camera manufacturers really do need to in the future include motion detection events and notifications in all cases. Which rumor has it at least that Hikvision is at least thinking about that in newer firmware releases. Don

While this may seem like an odd or even not well thought out practice by Hikvision it's actually a fairly standard practice for Network IP Camera manufacturers to use. As you state the only way around this is to use continuous recording methods. Which at least gives you an out. It really is a programming nightmare to try and support alarm events like motion events and notifications as one of many examples. While/When PTZ controls are in use. So the usual approach is to not allow motion related events and notifications to take place while PTZ controls are in use. If I was a betting man I would say that sometime in the near future updated firmware will support reporting motion detection events and notifications where PTZ controls are being used for Hikvsion auto-tracking reasons and not manual PTZ use. That said, this will still require extensive coding changes to support because the instant any PTZ control is used. Many if not all motion detection events and notifications are suspended until PTZ controls have come to a stop. This is to avoid false positives for motion detection. Most likely things will change in the near future to support motion detection events and notifications for any auto-tracking use of PTZ controls. But, most likely, when one is manually using PTZ controls motion detection events and notifications will continue to not be supported in many cases. I say this for good reason. Currently PTZ controls each time they are used suspend motion detection events and notifications. So code would need to be changed for each PTZ control not to do this "If this or that". While this sounds easy it's defining the "If this or that" vs. always as it is now. Worse, there currently are no methods to determine if a specific PTZ control was fired using auto-tracking or manually. So it may actually come down to adding PTZ control logic where one could instantly determine if the current PTZ control was fired manually or automatically for auto-tracking purposes. Don

1. Please stop making incorrect assumptions about my experiences and background with Network IP Camera equipment. 2. Since you refuse to so much as provide the brands and models of Network IP Cameras which you are making your statements about. It's not virtually impossible. It's impossible, to determine what sensors those cameras have in them. One would think you could understand that, as you continue to hurl your unfounded insults. When/if you decide to provide any more ("details") besides using words like "older" and "newer" then it would be possible to verify what hardware is in those cameras. Don

What are the camera sensors in the cameras you are comparing? Brand and Model of the sensors inside the cameras please? Facts not fiction please. Because it does matter. It's impossible to make blanket statements that all Network IP Cameras which say they are 4 MP will always be superior in low light compared to all 3 MP Network IP Cameras. This is because the sensor used in those cameras, can and does make massive differences on how they can handle low light conditions. While image comparisons are good. Camera sensor Brands and Models are better. Because it allows full camera sensor specifications to be cross referenced. Don Again, no one said ALL 4mp are better than 3mp..in fact in most cases higher mp cameras perform worse in low light you obviously have not been reading my posts. That is why inexperienced users who jumped on 3mp pr 5mp cameras without adequate lighting were sorely disappointed. 1.3mp and 1080p cameras handed low light much better. Please read carefully. What I said was that the new hikvision 4mp WD and 2mp WD cameras perform better than the older 3mp cameras in low light. You live in an abstract academic benchmark world which is typical of amateurs. I could care less who makes the sensor or what sensors is used. All I care about IS THE ACTUAL IMAGE QUALITY when installed and operating in the real world. Please provide the camera sensors Brands and models, used in the cameras you are comparing to each other. This allows their full specifications to be crossed referenced vs. simply ("only") your words. Facts please vs. words like "older" and "newer" generalized statements, that carry no meaning since one can't use "older" and "newer" to get real comparative specifications. Your inability to avoid insulting others while you attempt to present your opinions without any supporting facts is legendary as well as self-documenting. Camera sensor Brands and models for the cameras you are claiming to be different. Not much to ask for really. Don

What are the camera sensors in the cameras you are comparing? Brand and Model of the sensors inside the cameras please? Facts not fiction please. Because it does matter. It's impossible to make blanket statements that all Network IP Cameras which say they are 4 MP will always be superior in low light compared to all 3 MP Network IP Cameras. This is because the sensor used in those cameras, can and does make massive differences on how they can handle low light conditions. While image comparisons are good. Camera sensor Brands and Models are better. Because it allows full camera sensor specifications to be cross referenced. Don

I am quite against 3MP or 4MP or 5MPs, to keep coming on the market. 4MP cameras are using the same image sensor as 1MP cameras. They are charging more expensive than 1 MPs. They simply increased number of pixels, cheating on innocent CCTV customers. It may need a lot years to get 4MP true resolution-high fidelity, available in the CCTV market. I do not think it good to keep promoting 4MP cameras, in spite of the fact many of commercial monitors and large LCD TVs are quite limited to 1024 X 1280 resolution (SXGA). Personally, I'm not so much against 3MP - 5MP network IP Cameras as much as those that make claims about how good or bad this or that is based solely on the X MP that are claimed to be supported ("Usually from a sellers page, alone"). Without any attempt or need to verify what hardware is actually in these devices. Including camera sensors, CPU's, DSP and so on. Sure miss the days where someone took the time to do a tear-down and get to the meat and potatoes of what hardware is used inside a Network IP Camera vs. only reading a spec sheet that the seller supplies. These days, it seems more about the "Deal". It's not important if the device can ever be updated firmware wise. It's not even important if one can really truly get X MP out of a camera. Nothing seems to exceed the need for the "Deal". Which amazes me, since generally these devices are used for security. Go figure! Don