Very dissatisfied with DiVis...

[stratcat 0]

Hi all --

 

I'm new to the board. I initially stopped by looking for an alternative to DiVis' crappy software. My biggest headache with it is the fact that the video, and capture, is very choppy. Often the stream pauses for two seconds before continuing on. The never ending login dialog boxes are a pain too but I can live with that if the app worked well.

 

This is on a wireless CCTV home interrior/exterrior setup.

 

Well, I downloaded all the client DVR software that I could find (most of which was off the sticky DVR Software thread here) but none of them will show an image from the 311DI CAP-120A16 board that's functioning as my capture card. It appears as though most of the software goes through DS (directshow). Apparently this card doesn't have a DS driver. At least one that I found.

 

I saw the thread about the DiVis dev kit but figured I'll take the path of least resistance first. Before I do, I'm wondering if anyone has already done this - I'm a lazy architect and software developer by trade...

 

I think the choppy video is caused by the constant disk writes the software does. I looked at all their disk activity and it's so utterly inefficient that I; 1) am amazed that someone would release software this poorly designed, and 2) they constantly write to the disk in very small increments. This causes an over abundance of ring 3->0 transitions that steal cycles (in many forms) from the software to say the very least. So, I'm going to just hook their file writes to reduce the user/kernel transitions and (if I don't see enough benefit from just that) I'll ensure that all the disk writes are performed asyncronously.

 

Has anyone already done this? It seems like someone must have if there really isn't a well built DVR app that will recognize the card.

Edited September 30, 2007 by Guest

[rory 0]

Hi, are you sure its not:

 

1-The FPS limit on the card - what model is it?

 

2-The wireless camera/receiver - did you test a camera plugged directly into the card?

 

I dont know the card though so cant comment on its software.

[stratcat 0]

Thanks for your reply Rory.

 

1: FPS limit on the card is 120 and I only have this camera plugged into it. I have the settings set to 30 FPS. Same choppy video if I set the FPS to "Auto (MAX)". It's a 16 camera card.

 

 

2: I didn't plug the camera directly into the computer because it does not have a cable coming out of it _to_ plug into the card. I did test it with the wireless camera sitting three feet away from the receiver and therefore the system monitoring the camera. No change in choppiness unfortunately. Same results if I use a different camera sitting right next to the receiver.

 

DVR software and card are Divis'. It's their CAP-120A16 model.

 

**** As far as my investigation went to determine where the slowdown is ****

 

Fortunately, their file operations are asynchronous with the video input thread. That's good and means that the rate by which they take in new video is not tied to the rate by which they write that video to disk. However, they get demerits for using MFC. Didn't MS Outlook teach them anything?

 

So, what I did was I hooked into (e.g. hacked) their DvrMain.exe app - which is the thing that renders the images on screen and writes to their database (and a database catalog) file(s). So now I controlled the API that they call to create/open a new file as well as to write the data to disk. I bailed out of the API to create/open files early whenever they tried to write to their error log. They have a secret mechanism for writing a log file to the C drive. That's a very poor idea since that drive may not be the system drive or may even not exist under Windows. I didn't check to see if they get the drive letter the correct way or not. Anyway, derailing that gives us more CPU for other things now.

 

Then I put a sleep (e.g. a 2 second pause) in the call they make to write data to the disk. 2 seconds is long enough to severely interrupt the video given the rate by which they're calling the API. I didn't see a slowdown in the video so that means its on a different thread and is not synchronized with the file writing thread. That's good and expected.

 

So, now I'm back to where I was. What the heck is making this video so choppy? Are wireless cameras normally choppy? I get a lot of error messages in their secret log file that read something that doesn't mean much to me - perhaps someone here knows if its pointing out something I could do to make the framerate more consistant / less choppy.

 

[ERR] CH[2] Dropped by Overlflow!!!

CH[2]ReadFromBuffer => R:2 W:0 C:2 Succeeded

[ERR] CH[2] Dropped by Field Interval!!

 

Those are the three log messages that make up all the logs - and they get spammed out a LOT; like megs.

 

The "Dropped by Overlflow!!!" message - which I assume is a spelling error and should be "Overflow" happens very frequently. I take this as the video is coming in too fast for the software to either pull it off the card or to store it to disk. If that's true then I really need a way not to lose those frames as it's probably why I'm choppy.

 

The "Dropped by Field Interval!!" error makes up the rest of the log file (that aren't "Overlflow" errors). I wish I knew what was being "Dropped" and whath "Field Interval" is appaprently set too low; or perhaps that indicates a 'field' that should contain an expected value that is invalid.

 

If anyone has a direct show driver for this card I'd really appreciate a copy of it; if one even exists. I'd like to write a small app to see if I can't get a fluid framerate like I was promised. As it is, the video captured would have a person walking down a hallway, jump to the middle of it, and then you'd see them walking out of frame. In that time the person could have put something in their pocket. So this does me little good really.

 

I'd love to hear from some people that have wireless (non-IP) systems to compare notes. The color quality of my computer web cam is better than this "real color" thing. This is the camera I'm using (it's supposed to go B/W if the light is too low):

 

Color Mode:

- Color 380 TV lines of resolution

- 542 H x 496 V pixels

- 0.5 lux

B/W Mode:

- B/W 380 TV lines of resolution

- 542 H x 496 V pixels

- 0.2 lux

General:

- Sony 1/3" Super HAD CCD

- S/N Ratio: 52dB (min) / 60dB (TYP)

- Shutter: 1/60 ~ 1/120,000 sec

- 12 DC, 85 mA

- Dim: 1.25" x 1.25"

Included Items:

- 2'cable (extendable w/ standard RCA)

- Regulated power adapter

- 3.8mm conical pinhole lens (75 deg.)

 

Any help is very appreciated. The system I'm running this on is fairly slow (e.g. 1.4Ghz single core) and an AMD - only 512 Megs. It should be enough for software like this. Anyone have experience claiming different?

[scorpion 0]

The wireless camera is not going to be the problem. What are you using a Swann wireless?

 

I do not understand why you would buy that board based on your computer skills.

 

I will assume that this is birthday gift that was purchased for you, or is this something that you picked up off of EBAY on a fire sale?

 

I assume you have orderd the development kit.

http://www.divisdvr.com/sources/pd_sdk.htm

 

Now that you do not like the software will you be trading to a different product?

 

You are using a wireless product that is probably listed at 300 feet line of sight, or it is listed at 100 milliwatts of power. This is probably on 2.4G herts which tells me this system is not being used for security purposes. It is being used for simple home surveillance. If this is the case then the

divis should blend in to this set up with no problems.

 

I believe this is a 16 channel DVR, and you say it is 120 FPS. What is 120 frames per second divided by 16? 7.5 FPS? That may be the start of the choppy video. What kind of mother board/chipset are you using?

 

There may be some compat probs with you M/B. I bet you have this Divis in a really nice M/B with an AMD chipset. This would confuse me as it should work fine with this setup. If you have another setup than post it so we can take a look.

 

I would not be concerned about the choppy video as long as it gives you the video that you need in case you are broken in to.

 

If security is of the essence then I would suggest going to a different product. A security system with 16 channels should cost you more than $300.00 other wise it is just a toy.

[rory 0]

Dont know how you got in their API and .. dont wanna know (on the forum at least ). I know about hooking but normally would need to know the app a little more indepth to know what to hook, and the commands?

 

Anyway, actually most current DVR software needs alot more than that. For example, older versions of GeoVision use to run on 2Ghz but now it needs much faster CPU and alot more memory - I know as I use a 2.0Ghz AMD with 512MB Ram ..

 

As to the Driver, to get the Bt878 driver to work for your card, you will probably need to do what I did for the GeoVision. Basically download and run BTSpy: http://btwincap.sourceforge.net/download.html

 

To use BTSpy you would open up the DVR Card's program, enable all cameras and views, and watch some video. Then run BTSpy and it would create a custom text file to be used in the Bt878 Driver installer. Thats how I got it to work with a GeoVision card. Should be some directions with the BTspy program, I havent used it in a long time.

 

DiVis is Chance-i, they are supposed to be good, though I have never used them. Have you tried to contact them yet regarding the problem? Also, I would try and get my hands on a hard wired camera to test, could be a problem with the video server. If you cant get a hardwired camera, try and plug the TV into it to test (video out on the TV using an RCA cable and an RCA-BNC Adapter to the DVR).

 

Going by the specs though, it is more than likely the PC. See if you can try it on at least a 3.0Ghz Pentium 4 or similar AMD, though since most cards require the Intel Chipset, you may need to look for one of those. If it was a GeoVision, straight away I would have said first change to an Intel Chipset, then get back to us. Just the way it is with these cards.

 

Rory

Edited September 30, 2007 by Guest

[scorpion 0]

What is the IR range on your camera? Take that distance, and cut it in half, and this will be your effective range. If it is wireless than the LEDs that they put in the camera will not draw a lot of power as it is designed to work off of a 9 volt battery, which means the IR LEDs will not be very powerful. I am guessing that they have a range of 10 to 15 feet, but this is good as someone standing near that camera is going to be 5 or 6 feet away from that camera, and bam, busted on tape!

 

If you have a lot of trees, and you have a "canopy" then you will get a little more distance out of it.

[ClosedCircuitCom 0]

i highly doubt your pc setup is capable of handling the divis card. always stick with intel when building dvrs also 512 ram is too low at least a gig is needed. what type of video card are you using?, chancei suggests any 128mb ati card