kaon

It's true that HDD price has dropped, but to my customer, the ability to retrieve footage from say half a year ago is still important. E.g. Suddenly something crops up today where the footage from half a year ago is important to solve the case. Right now, the standard deployment is Dahua 2U embedded DVRs (8 SATA), filled with 8 x 4TB = 32 TB, per 16 analog cameras. This gives about 3 months worth of FIFO storage. We are beginning to deploy 1080p IP cameras at critical locations, but we hope to maintain or further improve in terms of number-of-months worth of FIFO storage. How many days of storage do *your* customers typically want to have?

Anyone? How about systems where face-detected zones are encoded at highest bitrate, while other background scenery are at lowest bitrates?

Thank you for sharing. You mention their CMS, is it free or paid? Is their software downloadable from somewhere? If you are interested in dealing over email with a guy in China Jufeng, PM me if you want his contact info. I have 4 different model IP cameras and a 8-bay NVR (all Jufeng) arriving soon for testing. Anyone else?

Is there a system for CCTV, analogous to security guard tour patrol logging system? (i.e. Where guards with a handheld digital logger device visit the RFID buttons fixed on walls of the premises, to enforce guard patrolling at the required times.) Nowadays, there are some security guards that are tasked with watching live-feeds, alone in a room. What systems exist to ensure that guards are watching the live-feeds attentively? How about a dialog-window that randomly pops up on screen and requires clicking it within X seconds?

Does anyone use Jufeng IPC and NVR? Please share your experience. I am told that XM (Xiong Mai) http://www.xiongmaitech.com/en/ manufactures the PCBs and writes the firmwares, that are then used by many other companies to make complete IP cameras and NVRs. Is it true that Jufeng http://www.jufenginfo.com/en/index.php is a subsidiary of XM? Jufeng makes complete IPC and NVR from components from XM, right? Does it mean that Jufeng will have better access to technical support from XM? Does it mean the Jufeng will have the latest stuff from XM first, and offer better pricing? I can see that Jufeng's IPC price is < Hik < Dahua. Is choosing Jufeng (over Hik, DH) a no brainer for own commercial use?

Is the HDCVI signal digital (like DVI/HDMI) or is it analog (like VGA/Component, CVBS, S-Video)? Is the picture degradation due to increasing length / interference gradual?

Hi all, After googling, I see that (a German brand I've never heard of) GEUTEBRÜCK has these fading quality storage products. News articles online about this FLTM feature date back to 2008. Here's what I imagine FLTM to be: For example, keep footage at full quality until it is 30 days old, then re-encode with lower mpeg4 quality or lower frame rate and keep for further 60 days. At 90 days of age, it is further compressed for an even longer retention time, and so on. Does any one else make DVRs with this type of feature built in?

Here is video showing that the lowest (768 kbps) and highest (4096 kbps) VBR "Bit Rate" settings do not appear to make a difference to the INFO>BPS during high-motion scenery. In both cases, BPS maxes out at 800~900 MB/hour, when in Record type: MD. 7Yn-ArQNHOA Again, if recording type is set to REGULAR, then the "Bit Rate" setting seems to act like a maximum cap. Interestingly, the INFO>BPS can exceed 1000~1200 MB/hour when Record type is REGULAR. But if Record type is MD, then the INFO>BPS never exceeds 900MB or so, (in high-motion scenery). All the above is with DVR1604HF-S, firmware build-date: 2012-05-30, PAL, D1, 25 FPS (full frame rate), VBR, Quality=3.

I don't think ARP/DHCP are the crucial parts that OP is asking about. Sure, those need to be done in order for your DVR to be reachable from other machines in your LAN. But they will not allow your DVR to be reachable from any outside browser from across the internet. I suspect that the DVR has auto-negotiated with your router, via UPNP, to get port 80 forwarded to the DVR. When this has been automatically set up, browser requests from across the internet to your WAN IP, are forwarded by your router to your DVR. Your router then acts as a middle man between your DVR and outside browsers.

Bruce of Dahua also wrote back with similar findings, if I may rephrase and simplify: - higher "Quality" setting gives clearer picture in stationary scenes. - higher "Bit Rate" setting gives clearer picture in high-motion scenes. However, from further tests, I find that the record mode (in SETTING > SCHEDULE) (REGULAR/continuous vs MOTION DETECT/MD) has an unexpected effect on how the VBR bitrate (according to INFO > BPS) changes. The above descriptions of how Quality and BitRate affect VBR behavior is true when RECORD mode is "REGULAR". When RECORD mode is MD, then the VBR "Bit Rate" setting seems to only affect how low the VBR bitrate is allowed to drop to during stationary scenes. It does not act like a maximum cap. It acts more like a minimum.

After 20 minutes on the phone with Bruce of Dahua, (With him looking at the same screenshot above), I still wasn't hearing an answer to my question. He repeated the same old generalities about CBR and VBR a few times, and asked me to repeat my question a few times. I said I wanted to understand in more precise terms, how the "Quality" setting and the "Bit Rate" setting, both affect the VBR behavior. He told me he would email me a more complete explanation later, and I said OK. I got the email... here's what he wrote. After some experimentation, using the "MENU > INFO > BPS" page, and a 1to3 video splitter, allowing me to feed the same analog signal into 3 input ports, my findings are: - On static scenes, higher "Quality" produces higher actual bitrate. - On static scenes, (esp. with low detail), the "Bit Rate" setting has almost no effect on actual bitrate. - On high-motion / high-detail scenes, the "Bit Rate" setting works like a maximum cap. With corresponding blockiness when the VBR is constrained by a low cap. - The effect of "Quality" on actual bitrate can sometimes be hard to see. UPDATE: the behaviour described above holds when RECORD mode (in SETTING > SCHEDULE) is set to REGULAR. BitRate behaviour is completely different when RECORD mode is set to MD (Motion Detect).

This is the ENCODE page of the Dahua DVR1604HF-A. Does the "Bit Rate" setting have any effect?

Hi all, I have been looking at analog cameras from Dahua and Hikvision. I would like to understand more about WDR vs DIGITAL WDR. (at least when restricted to Sony Super HAD II and Sony Exview HAD II) Is one better than the other? It seems to me that only Super HAD II has (non-digital) WDR, and only Exview HAD II has DIGITAL WDR. See: http://www.hikvision.com/en/Products_show.asp?id=6118&showid=1 I have vaguely gathered that the terms "Super HAD II" and "Exview HAD II" refer to the sensors, while "Effio-E/S/P" refers to the DSP chipset? (With E being the basic one, S for low-light oriented, and P for WDR ?) The type of Effio chipset used is only stated in some datasheets, and not others. In the Hikvision series above, they have 3 Exview models specifying Wide Dynamic Range: Digital, and 1 Super HAD II model specifying Wide Dynamic Range: 75 dB. Can anyone point me to an explanation of all this?

I'd like to know too. They come in 1/4" 500TVL as well as 1/3" 600TVL. I gather that DIS is a integrated sensor+DSP system-on-a-chip arrangement, as opposed to separate chips for conventional CMOS and CCD cameras. It is not clear to me if the underlying sensor type is CMOS or CCD or something different.

http://www.youtube.com/watch?v=vQaTjSs0cvc This video looks like it's done by Mobotix marketing dept. What they claimed was surprising to me, because I had assumed that H.264 streams from IP cameras do not need to be decoded in order to be recorded. From what I understand, decoding the stream at the NVR would only be done if there are some video analytics to be done, or during "live viewing", or during playback. An NVR that decodes H.264 and then re-encodes for recording, is poor design, because it wastes CPU cycles. A sensible NVR would accept H.264 streams and at most repackage the stream in its own container format, this should not be CPU intensive. Am I mistaken?