Stereodude

The same thing happened to me. If I'm remembering correctly after closing my browser and restarting my browser and logging back in I could change the fields again.

So my seller came back and told me there was no newer firmware for the 3MP camera than what came on them. As I mentioned earlier in the thread I put the General_IPC-HX3XXX_Eng_N_V2.103.0001.0.R.20120914.bin on the 3MP cameras and it worked fine and fixed several of the issues I was having. One thing I noticed yesterday is that I can now pick 20FPS at 3MP H.264 instead of being limited to 15FPS.

I didn't buy mine from China. I bought mine from a US based retailer. They are not branded as Dahua on the packaging or cameras. They are listed as Dahua cameras on the retailers website though. I have been working with my retailer to get firmware and software updates.

So, after running them a full day with the new firmware, the exposure issues seem to have been tamed. Over night between the two 3MP cameras I got 1 false recording under constant darkness where I was previously getting dozens per camera. They seem to respond better to real motion in the frame, and they don't seem to experience random flickers / exposure pumping that triggers recording. On a sensitivity of 4 I still get a recording when the camera adjusts the iris / gain (which could be eliminated out with a little clever programming), but I'm getting probably 80% less false clips (because there's no more from random flickering / pumping) during the day. The 20120914 firmware is definitely a big step in the right direction in fixing the gripes I had with the cameras.

I'll share it. I don't mind. I wouldn't want anyone to think I'm distributing a hacked firmware to brick your camera or steal all your files and computer secrets though.

So I tried the firmware on the ipc-hfw3200cn, and it updated / upgraded the camera without any issue. It improved the FTP behavior of the camera (one of my complaints). The camera now has HLC and WDR. I decided to roll the dice and try the firmware on one of my ipc-hfw3300cn cameras. It also updated / upgraded the camera without any issue. The FTP behavior improved here also. HLC and WDR are now also available on the ipc-hfw3300cn as well. Since it worked on the first ipc-hfw3300cn I tried it on the second and had success there also. It's too soon to know if it improves and of the exposure pumping or flickering, but I've got my fingers crossed. If nothing else, the cameras aren't doing a near DoS attack on my FTP server anymore (sending >500 commands a second to the server between the 3 camera). CPU usage of the FTP server on my PC is now between 0-5% instead of 20-30%. " title="Applause" /> I'm curious to see what firmware they send me next week that's for the ipc-hfw3300cn.

So you can modify the .bin to add a backdoor, but you can't modify the bin to change the code and correct errors? How can you add a backdoor if you can't modify it?

That's totally different. You have the toolchain necessary to generate a custom Dahua firmware. You're not reverse engineering anything and hacking anything. You're using a tool provided to you as a reseller from the manufacturer that allows customization of firmware and spits out a semi-custom .bin file. Can you generate a .bin that will brick his camera or install a backdoor? Further, if I had that sort of access and capability why would I be here posting about trying to get the latest firmware for my camera? I would be able to fix the bugs in the firmware myself.

Why wouldn't he? It's a .bin file. Do you understand the level of complexity and extreme difficultly of doing any of the stuff you're talking about by manipulating a .bin file?

Well, they provided me General_IPC-HX3XXX_Eng_N_V2.103.0001.0.R.20120914.bin However, they said it's only for the ipc-hfw3200cn and that they would provide me a new firmware for the ipc-hfw3300cn next week. My understanding is that this firmware should be suitable for both. I guess I will wait and see what they send next week.

Maybe. I'm not sure if the physical size of the cropped portion of the 3MP 4:3 sensor is the same as a 2MP 16:9 sensor. As you probably know, sensor size does impact lens performance.

Thanks for the reply and the link. I've also requested an updated firmware from the vendor I bought the cameras from. We'll see if they reply with anything newer than the one discussed in that thread. BTW, did you mean WDR?

I can't say 100% since I don't have a Dahua NVR, but they do crop the top and bottom of the image when you use them with a PC set to 2MP. The 3MP Dahua bullet cams I have turn the 4:3 (2048x1536) image into 16:9 (1920x1080) if you set them to 2MP. They don't offer a 1600x1200 2MP mode. So, I would think the distributor was correct.

Can anyone point me to the latest NTSC Firmware for the IPC-HFW3300C? I've got 2 of them that report this about themselves: They're driving me nuts with incessant brightness pumping triggering the cameras built in motion detection and I'm hoping there is a newer firmware with better performance. Since the SoC controls both the iris and the gain on the sensor the fact that it can't filter it's own adjustments from triggering the motion detection is mind boggling.

I'm looking at some of the Dahua cameras and I noticed they all list the same max bitrate for H.264 regardless of the resolution. Example: IPC-HFW3300C (3MP) - H.264: 32K ~ 8192Kbps IPC-HFW3200C (2MP) - H.264: 32K ~ 8192Kbps IPC-HFW3101C (1.3MP) - H.264: 32K ~ 8192Kbps I guess the first question is are those listed bitrates really accurate? Using the same max bitrate as resolutions increases seems like it would be a recipe for compression artifacts on the higher resolution cameras. Second, what H.264/MPEG-4 AVC Profile & Level do the Dahua cameras use? Thanks!

I'm making no claims about his credibility. However, I'll take real world first hand experience over a theoretical white paper though. Do you believe the 0-60 time of a car measured by a reviewer who tried it or one calculated by a physicist? Another example of you arguing for the sake of arguing hoping no one will notice your shifting position. You're the person who said it wasn't realistic to compare the output from a DSLR to the Dahua camera yet now you're trying to do so. You're suddenly trying to draw some comparison of DSLR footage compressed using a CRF that was made with arguably the best low bitrate H.264 encoder as the basis that an "inferior" camera using the H.264 encoder in a Texas Instruments SoC that uses real time CBR encoding limited to 8Mbps will be okay. This has so many logical holes in it I hardly know where to start. Lets see we've got: Different cameras (sensors & optics) Different H.264 encoders Different encoding methods (CBR vs. CRF / real time vs. not) Lastly, I made no claims as to the quality or transparency of the H.264 output from x264 in the test clip. I'm not sure how you've concluded I feel it's okay. I simply ran a test demonstrating that lowering the frame rate of relatively static video does not dramatically lower the bitrate required to maintain perceived visual image quality.

Your confusion is completely understandable. jharrell is apparently arguing for the sake of arguing. He's simultaneously arguing both for against each side of the discussion in a big circle. He's claiming that low bitrates similar to the Dahua (also citing Netflix and iTunes HD), while at the same time claiming that it's totally unrealistic to expect the Dahua camera to have very good video quality apparently because they're not expensive enough. The first point is effectively irrelevant to the Dahua camera's H.264 quality because AFAIK no Blu-Ray, Netflix, or iTunes HD content has been compressed using a Texas Instruments SoC. The existence of high quality low bitrate HD H.264 isn't in question. The ability of the Ti SoC to generate high quality low bitrate HD H.264 footage is.

I never said that. I simply pointed out that your conclusions are highly misleading. I compressed a real clip using a H.264 encoder holding the perceptual visual quality constant and your retort is a white paper. If you lower the bitrate in the matter you're suggesting you will see artifacts. I also never said that. You seem quite apt at trying to attribute things to me that I didn't say.

What I said is even more true for static video. Frankly, I don't care what a bandwidth calculator says. I've got enough hands on experience with H.264 compression to know that decreasing the frame rate does not dramatically reduce the bitrate required to encode relatively static video to the same perceived visual quality. To illustrate my point I encoded a nearly static 1 minute 1080p30 clip a I shot out my window this morning with my 5D MkII. The camera is stationary and the clip has limited motion. The only motion is that of my neighbor cleaning the snow from their driveway and sidewalk with a leaf blower. That motion only comprises a small portion of the frame. I encoded it with x264 several times using a constant rate factor (ie: constant perceived visual quality). Each time I encoded it I lowered the frame rate decreased by decimation (not slow motion). 1080p30 - 1799 frames, 4.52 fps, 6881.12 kb/s 1080p15 - 900 frames, 3.44 fps, 6184.12 kb/s 1080p10 - 600 frames, 3.04 fps, 5454.42 kb/s 1080p7.5 - 450 frames, 2.44 fps, 5486.03 kb/s 1080p6 - 360 frames, 2.42 fps, 5457.01 kb/s 1080p5 - 300 frames, 2.37 fps, 5315.40 kb/s

That may be true for averages over the whole 90+ minute movie, but there are lots of points in a movie where the instantaneous bit rate is over 35Mbit/sec on movies that don't use the MPEG-2 codec. I'm not sure how you think I'm expecting blu-ray quality. I've been the one stating there's no way it can have blu-ray quality video because the bitrates are too low and the encoder has too much going against it. I asked if the video quality was reasonably transparent or a mess of compression artifacts. Cutting down the frame rate does not half the required bitrate with H.264. It does reduce it, but not nearly by half. There are less frames to encode, but the changes between them are then twice as large. Also, the lower the frame rate the longer you have visually to look at each frame and are therefore more likely to notice compression artifacts. As a result you end up reducing the bitrate somewhere around 25% for the same visual quality when you cut the frame rate in half. Aside from arguing with me about the bitrate used on Blu-Ray discs, you ultimately seem to be telling me that I should expect a mess of compression artifacts since it's not as good as broadcast ATSC HD.

I'd bet these rules of thumb originated in the days of token ring and when everyone used hubs not switches. Many of the concerns people had may not be valid any more, but the "rules" are still followed. It I was doing IT at a business I wouldn't want them on the same network either due to security concerns. I wouldn't want someone to be able to unplug a camera, plug in a PC and have access to the network. At the least I would want to have them on their own VLAN if they shared a physical switch. Putting them on their own physically separate network would allow for the camera network to have it's own backup power and other potential advantages. They're also protecting themselves from a "what if" scenario and blame later. I get that. However, the point still remains that a few camera moving traffic between two ports on a switch isn't going to slow down other data moving through the same switch. Even with a relatively low end consumer grade switch.

No, that's not what I did. The scenario you're describing above makes no sense to test. I tested your claim that moving a large amount of traffic between two ports on the switch in his router would slow down other traffic through the switch in the router. I moved 90Mbit/sec from port 2 to port 3 (simulating the PoE switch to NVR connection in the router's switch) and simultaneously moved 900+Mbit/sec from port 1 to port 4. The 90Mbit/sec moving between port 2 and port 3 had no impact on 900+Mbit/sec data transfer speed between port 1 and port 4. There was no slow down from the simulated camera to NVR traffic going through the router's switch.

That's just not true. His Asus router has a four port gigabit switch in it. Yes, his PoE switch is 100Mbps. That's quite the interesting spin you're trying to put on things after I directly disproved your claims. I said it didn't matter if he connected the PoE switch to his router's switch and then connected the NVR to the router's switch or if he connected the NVR directly to the PoE switch and also connected the PoE switch to his router's switch. You said that connecting the NVR to his PoE switch through his router's switch would slow down his home network. I proved that a saturated 100Mbit link going through the switch in a consumer router like the OP's would not slow down his network.

You said that would slow down his entire home network. So, I decided to test your hypothesis. I tested using a consumer grade router with a gigabit switch similar to the OP's. Saturating a 100Mbit link (~90Mbits/sec) between two ports on the switch did not slow down other traffic through the switch. I measured 921Mbits/sec between two gigabit endpoints while the saturated 100Mbit link was pushing traffic through the switch. With the 100Mbit link removed from the switch I measured 918Mbits/sec between the same two gigabit endpoints. So much for that theory...

Why don't you try it both ways and see what works best for you? My guess is you won't find a noticeable difference between them.