Jump to content

stroonzo

Members
  • Content Count

    64
  • Joined

  • Last visited

Everything posted by stroonzo

  1. stroonzo

    Dahua firmware

    I can report that the PAL version that was posted earlier worked just fine on my two HFW3200S street cameras and my 9 HDB3200C mini domes. And the NTSC version posted this morning works on them as well. Now tonight, I will be able to see if the NTSC version fixes the HPS lighting flicker.
  2. For testing, I put a 6mm, IR compatible lens on the 3200 mini dome. The night time usage is improved, but trying to run color in the day is useless of course. So much for being an E-Day/Night. I'll post some pictures for comparison once I finish all of the testing. I am going to see how the mini dome responds to an IR Illuminator at night, how it runs during the day in night mode (B&W), and do some shutter speed comparisions to the other dome covering the same general area. In the end, I may find the dome to be a useful conversion to a full-time B&W camera.
  3. stroonzo

    Dahua firmware

    Hey, THANKS! This is great.
  4. Are the Dahua IPCs all using the same wavelength IR? I have a couple of IPC-HFW3200s that I am thinking about adding some additional IR to. I think they're 940, but I want to make certain.
  5. The specs for the state: IPC-HDB3200C Day/Night Auto(Electronic)/Color/B/W. From this can I assume then that the lenses on those domes are using a built in filter and that is the reddish glass glued on to the back of lens (the backside of the lens visible when the lens unscrewed)?
  6. So it is safe to stay I should stick with the 850 / 880 illuminators?
  7. stroonzo

    Dahua firmware

    Pelo666 - if there is any way you can get the NTSC version; that would be a LIFESAVER! The PAL version works fine except for one particular situation - Street Lighting. It seems the high-pressure sodium (HPS) street lights quickly (undetected to the eye) flicker in sync with the 120v / 60Hz power supplied to them (through the 60Hz ballast). Because the PAL firmware is 50Hz based, the only way I can get a usable picture at night (when the street lights illuminate) is to use a 60Hz anti flicker mode. The unfortunate issue with using the 60Hz anti flicker mode is the very limited shutter selections. It appears as if all of the Outdoor shutter settings are tuned to PAL standards and are all unusable. Maybe this is not the case and maybe this is just a weird issue with CCTV cameras and HPS lighting. I sure would like to test with an NTSC firmware on these cameras. To explain better, these are two cameras used specifically for LPR. So the shutter speed at night is needed at 1/500. Using IR reflection, the plate info can be seen while two other cameras much further back are picking up the general overview. Oh where, oh where is the NTSC version? In fact, I'd be happy with previous firmware (the last one back - 0313) in NTSC if you have access to that.
  8. stroonzo

    Dahua firmware

    Well, let me report that I just flashed my two HFW3200S street cams. I already love the individual profiles for day and night mode. Now I am just waiting for night time to come so I can get those settings right.
  9. stroonzo

    Dahua firmware

    I am going to flash mine too. I would love to have the Day vs Night settings on my HFW3200S cameras on the street capturing plates. I sure hope this isn't a hacked up firmware embedded with a Stoned Empire Monkey. I mean, Pelo666 just joined and the first post was an elusive Dahua Firmware. And the user name is comforting as well. Last I checked, Flushot Plus doesn't inspect Dahua Firmware files for hacks. Since we know the flash actually works, I guess the worse to happen now is it just has a potential backdoor. Oh well. There are worse things in life. Maybe there is a 1 out of 8 chance when the camera reboots it will display the message: Your IPC is now Stoned! I really crack myself up sometimes! yes, rememeber that: http://en.wikipedia.org/wiki/Stoned_(computer_virus)
  10. I captured this the other night. I woke up that morning, looked out of my front window and noticed my neighbor's car up on MY landscape stones. I have since burned this to DVD and submitted it and the YouTube link (so they're able to see it it in 1080 rather than DVD's 480) to the police. See, everyone thinks I am weird for having cameras UNTIL something happens to them. Then I am the one who is asked "you think you got them on camera...?". What isn't understood is - my system and lighting is specifically designed for my house. It is just by chance I may get footage of their home. I tell you though, this particular incident really has me thinking about putting two LPR cameras on the light pole in the front of my house (facing down the street in each direction). Although the video makes the lighting appear to be somewhat bright, it isn't. In fact, it is quite dark. The cameras (being non IR) are set to a shutter speed to compensate for the low lighting. The result is much better light sensitivity and less noise. The effective frame rate therefore is about 10 FPS. This is really about as good as it gets with 1080P cameras without IR at night. These are Dauha IPC-HDB3200C 2 Megapixel Full HD Vandal-proof Network Mini Dome Cameras. Here is the link: (or if the BBCode decides to work):
  11. It has been surprising to everyone, including law enforcement, that they took SO LONG. It was assumed the thieves were in and out in only a few minutes (not 13). Also, it was surprising to them that they used little to no stealth in the event. This video has been helpful. There has been a string of these thefts occurring around here. In fact, that night three homes were victim to this identical crime. With this footage submitted to local law enforcement and posted to our neighborhoods presence on NextDoor.com, everyone is on the lookout. There is so much more motivation for people to look out for these criminals. People become very charged up and motivated by the footage. Regarding the North Camera - yes, increasing the FPS in trade for higher noise has been a consideration. After this event though, I will be installing two LPR cams on the street light pole in my yard. That's gonna be awesome!
  12. My neighbor's home burned down and he died in the fire in 2009. The title and mortgage situation is just getting all finalized for the property to go on sale. Soon after being posted for sale, I am sure it will be sold in no time. Our area is growing quickly.
  13. I have been evaluating Digifort Enterprise for about 10 days. The following system and setup have been configured for the evaluation: Server: Intel S1200BTSR Server Board Xeon E3 1240 V2 Ivy Bridge (four core, eight thread) @ 3.4 Ghz per core ECC RAM 96 GB Kingston Hyper X SSD 2 x 3 TB Seagate 7200 RPM in RAID 0 (6 TB video volume) Windows 7 Pro 32 bit (recommended to run Digifort) Integrated on-board video Intel 82574L Gb Network Adapter Client: Core 2 Quad Q8200 @ 2.33 Ghz per core Intel SSD Nvidia 8600GT (old) 4GB RAM Windows 7 Pro 64 Cameras: 9 x Dahua IPC-HDB3200CN 2.0 Megapixel CMOS, 30fps @1080P, POE Switch: Cisco WS-C3560G-24PS (POE, Gigabit, running the latest IOS) I have the bitstream of al cameras jacked up to the highest setting at 8Kbps The server just eats this up. My friend is running an almost identical setup but with 12 cameras. My 9 camera system doesn't phase the Xeon E3 1240 V2. My CPU utilization hovers only around 16% Now the client workstation is a whole other deal. Yes, it is a rather old CPU that benchmarks significantly lower than my new Xeon based server. However, it holds up very well in viewing all channels in the D1 substream. There is no problem there. It isn't until I client-select a single camera in live view and it opens up in all of its glory at full blown 2MP, 8Kbps, 30fps that the skippy video begins to show. In addition, playback of a camera crawls (instead of having skipping frames). So cutting to the point of the post.... I have tested various scenarios and have determined without much doubt this is simply a decoding bottleneck. My question is - does anyone have any opinion on the success with a new nVidia Purevideo HD (5th Generation) GPU solving or helping with this h264 bottleneck? I figured it would help my poor Core2 Quad viewing station deal with the massive data stream coming into it. While my 9600GT has Purevideo generation 2 built into it (supporting full gpu decoding of h264) it is rather dated and since been significantly improved in all generations following it. Sure, I can throw raw CPU at it. If I use my server as a viewer (even with the lack luster integrated graphics), the problem is almost gone completely. On the other hand, i could lower the bit rate, fps, or resolution. But then I ask - WHY buy such nice equipment to just lower the quality? I just do not need a Xeon based workstation. Rather I was hoping a new GPU with the 5th generation Purevideo HD (like the nVidia GT 640 or better) would solve my issue. If a new GPU could solve my issue, I would rather do that. If not, I may be building a new client workstation on the same Xeon chip AND with my new GPU I will be buying to test on my current workstation. Does anyone have any experience with my situation?
  14. Swapping the server for the viewer client isn't a good option for me since my server is running VMWare and the Digifort Server is one of a few other VMs. Moreover, a friend with the same server setup has an identical viewer client as the server and he has the same issue. I think Digifort (what is supposed ot be the BEST NVR so I am am told) just isn't coded to work directly with nVidia Purevideo HD and take advantage of the h264 decoding it can do. I see that Eyesoft's NVR package supports nVidia. I may build myself a VM to test this out since it is a client / server NVR.
×