stratcat

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?

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.

Hey jepollard -- I have this card and can't stand the software. What are you using? I've tried a dozen different types and haven't found one that recognizes the card.