kaon

Any other reason why you are trying to save HDD storage? The price of HDD has droped down so badly, not worthy of the efforts.

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?

I have one Jufeng PTZ speed dome camera. It works great. Their CMS software is good, too. It supports ONVIF so it's the only PC software I have that will work with all my cameras - other than Blue Iris but Blue Iris is 10 times as CPU intensive as Jufeng's CMS on my machine - and that's 9 cameras on Jufeng CMS compared to 2 cameras on Blue Iris. If there was a US distributor or seller for Jufeng cameras I'd buy more.

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.

Yes, my question is when I am off-site. I am not having a problem, I am just trying to understand how the process works.

I assume that when I am out of my LAN, the WAN IP address will connect to the my router, and the router will point to the CCTV system. When I am local and look at my router set-up ("Attached Devices") I see the LAN address and the MAC address.

I would think there would be some indication of the type of device(?)

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.

For example:

Config A: VBR, Quality=1, BitRate=2048

Config B: VBR, Quality=6, BitRate=1024

If given the same camera input, which setting (A or B?) will have clearer picture?

 

In the above situation, the logic how DVR works is like below:

If there is few movement(I put the camera in the desk, then focus on the wall) where the camera installation. The Quality settings is very important for picture quality, in this time, config A picture should get worse picture than config B. If there is a lot movement(move your hangs always in front of the camera), you can see the picture quality(real BPS of this camera), Config A should be better than congfig B. But in project when you use DVR, we recommend you use Quality 3 or above, and the bitrate 2048 if you use all channel D1 DVR.

You can test in your side, in the DVR--menu-infor--bps, you can see the real bitrate after change the settings, it will be easy for you to find the difference between each settings.

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.

For the VBR and CBR, VBR means the bit rate will be changed with the surroundings. it will change a lot if there is not too much movement. and if you use CBR, the bit rate almost similar whatever the surroundings change or not. For example, if you set bit rate as 1024, in CBR, the bit rate will be always nearby.

 

And for picture quality, the higher the better. For example, if you set bit rate as 1024 VBR, compare the picture quality, 6 will be better than 1. In lower quality settting, the bit rate will be lower then higher quality settings.

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?

Surprised to see ZERO hits when searching this forum for Axxon.

I am being told by a vendor that it has more analytics features, approaching Milestone abilities, at a lower cost. But higher price+features than something like LuxRiot.

Does no one here have experience with it?

I did this via FTP for a while with an Axis camera server and a SAMBA server...

The directory was literally filled up with thousands upon thousands of individual JPEGs. The directory got so large that any attempt to browse it (explorer in windows) would literally choke/die/crash when you tried to open the folder.

I've never tried it with a megapixel IP camera... but imagine how painful browsing that directory would be.

The D-Links I tested could be configured to save video lengths at maximum of like 1 minute. So you do end up with many short files, though not as extreme as in your case. Since it would create folders for each day.

I have not found anything better.

Mobotix is too costly, D-Link is too buggy.

Some IP cameras (like D-Link) support recording directly into shared storage space. i.e. There is no NVR / DVR software.

What does everyone think?

Pros:

- avoids cost of NVR software and operating systems

- NAS boxes are cheaper than PC's

- less complicated, more reliable

Cons:

- Lacks advanced capabilities of NVR.. which are?

- some software still needed to do multi-cam-playback, video search?

It seems attractive to me. Or are there other major disadvantages?

Both Acti ACM-4001 and Dlink DCS-2102 are unable to reduce their bitrate during stationary scenes, by much.

Bitrate ratio is about 4 : 5 (bitrate during no-motion : bitrate during motion)

Axis's 1:8 ratio as mentioned by jhonovich is more like it.

Keyframe distance is variable.

It is 100% constant for the DCS-2102.

1 I-frame, 4 P-frames....

I cannot tell for the Acti ACM-4001, since it records in a proprietary container.

The encoder will make that decision on every frame. ... So instead of sending the difference between every pixel and last keyframe, it is more efficient to simply generate a new keyframe.

I know the above are the advertised capabilities of MPEG4, but implementations of wildly varying efficiencies by different companies seem to be labelled "MPEG4". Greatly complicates camera selection.

Fair enough. One note though. In MPEG-4 ASP there is sometimes accumulated error. That is, if you keep sending changes relative to the original keyframe, the image degrades over time. You can see this effect when watching a mostly static image and seeing it get better at regular intervals when the keyframe arrives. This is another reason keyframe distance is not set to too large of a number.

AFAIK, during stationary scenes, if the deltas are directly with respect to a keyframe, then we don't expect degradation. It is only when deltas are with respect to other delta frames, that we expect degradation to accumulate.

The answer is "neither" . MPEG-4 like other interframe codecs, sends out a full frame of video called I-frame.

I am testing ACTi ACM-4001 and DLink DCS-2102.

Thank you, yes I am aware of keyframes, and that some encoders accept a parameter for max-distance between consecutive keyframes.

Both cameras I am testing do not expose that setting, though.

Keyframe interval should ideally be variable, becoming less frequent during low motion, perhaps up to a max-interval.

For security cam videos, 10s interval is fine, especially if only exercised during stationary scenes. If the space-savings are significant.

Hi all,

I have a vague understanding that an MPEG4 codec could, in principle, be set up in constant quality (variable bitrate) mode, such that when there is high motion, bitrate increases up to a set maximum, and when the scene is unchanging, bitrate should approach zero. This is the ideal way things would work.

And then we should have no need to set record-only-when-motion-is-above-threshold. Since they can record stationary scenes with very little disk space.

Question:

How well do the various cameras achieve the above ideal?

A few possibilities for the poor performance I have been seeing:

- shoddy MPEG4 implementations

- constrained by processing hardware

I WOULD LIKE TO SEE THE FOLLOWING ADDED...

 

Their recorded video comes out as an executable (.EXE) file embedded with their viewing software. This is a nice feature and will give you full PTZ control over the video. The one downside is that you cannot e-Mail that file to another individual. Transporting the document footage becomes an issue. You can zip the file up but most e-Mail systems will run a virus scan on the zip file and think that the file is malicious and not send the attachment.

 

You could always change the .EXE into something that the mail server could accept, but I agree that this is a PITA. You can also export it as a native .ps file, but the player would not be included.

Some email systems are more sophisticated than others at detecting executables.

The simplests ones are bypassed by changing file extensions.

But executable files do have a certain signature in their data content, and can still be recognised.

So next up, you can put them in compressed archives.

However, systems like Gmail can see inside most archives, and will block zipped-up executables.

The workaround I know is to use password-protected zip archives.

However, all this is still non-ideal. I would also want an option to export in a standardized AVI container, preferably without lossy transcoding.

that's lame.. time stamp is a must but are you using their freeware or enterprise software?

It was their enterprise version.

But their free download version is very similar.

I think the main difference is in the max number of cams supported.

All CCTV DVR compression techniques are pretty lossy but those setting will significantly reduce your time to export when compared with the MPEG option.

The best AVI export I know of so far is that by ACTi cameras and their ACTi NVR.

Their native files have extension .raw, exporting to .avi is really fast, typically within 1 second for 10minutes of video. Filesize also remains nearly the same. This is exemplary, no transcoding, just a change of container format.

I have tested some ACTi 1.3 Mpix cameras.

Image quality is OK.

ACTi NVR has horrible usability. I have given ACTi my feedback, and they say they will work on it.

Both ACTi and AXIS cameras have the same problem with the internal real-time clock not being able to keep real time when unplugged.

NTP is required.

Otherwise the ACTi NVR isn't able to record properly.

In ACTi NVR, there is no way to export video with the time stamp overlayed in it.

I do like the lossless AVI export though.