Stereodude

After this, I figured I'd try the firmware update Stereodude provided - 2.103.0001.0.R, build : 2012-09-14, because why leave well enough alone? Anyway, the upgrade took, didn't brick my camera, and everything came back online with no issues, including remembering the most of the settings.

 

The only problems: I can no longer update these pages:

- Network, TCP/IP (all fields are blank, including MAC address, no updates possible on any of them)

- System/General web page (Device Name is blank, used to be the SN, and the Date&Time tab won't open at all).

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.

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.

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.

The fact that the products are sold directly from China (via small offices, not directly linked to DAHUA) make them cheap&accesible. But at a cost level, not at any other level.

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.

It's too soon to know if it improves and of the exposure pumping or flickering, but I've got my fingers crossed.

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.

You make some good points, but alas, Dahua makes it nearly impossible to get firmware any other way. The ball's in their court. They're the ones making casual users rely on the community for support.

 

I've said this many times before, but their terrible customer support and firmware support is one of their biggest weaknesses. I don't think they're listening, or if they are, they don't care.

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.

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.

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.

Not really... can be done via OpenSource tools - with a little bit of knowledge.

Yes, we could make a firmware with a backdoor (I suppose - although we will never do or try it)

 

Secondly, you can't fix any bugs... the whole system of DAHUA runs in a single binary format file... you can't modify it. But you can add to the embedded system some stuff.

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?

Well, actually, i do...

 

If you want, I can send you a modified firmware - with your name in the webpage or something... That would prove my point?

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 would you trust a firmware sent by anyone over Internet (just my opinion)?

 

Aren't you afraid that could brick your hardware or, worst, that someone "planted" a little backdoor in the firmware?

 

The source of your PC's OS is a forum?

 

Just curious and trying to raise the awareness level... we are talking about hidden free access to your cameras... We are also talking about security devices, video access and recording access - better than any malware that records your cameras!

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?

Heh! Yes, WDR. I work for Western Digital, and we're WDC, so the fingers were on autopilot!

 

If you get a newer version of software from your vendor, I'd love to get a copy of it.

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.

So technically they do become a standard 16:9 1080p 2mp camera. If the same lens was on a 2mp sensor in other words.

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:

Device Type IPC-HFW3300C

Software Version 2.100.0000.6.R, build : 2012-05-07

WEB Version 3.0.0.0

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.

So your saying Kush is wrong? Why do you have more credibility than him, he also claims to have done many real world tests to come up with this formula?

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?

 

So is 6Mbps ok or not considering 8Mbps is on the low side? I am confused now too.

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.

Can someone explain to me plz

What this discussion is all about ?

I am getting confuse

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.

So I guess you know more than Adobe video engineers.

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.

 

BTW hows that 1080p 30fps at 6Mbps, I thought it needed 40Mbps?

I also never said that. You seem quite apt at trying to attribute things to me that I didn't say.

Now go to any H.264 bandwidth calculator and compare 30fps to 15fps see what you get, here's one from Stardot security cameras:http://www.stardot.com/bandwidth-and-storage-calculator. What you said might be true in theory on scenes with a high amount of change such as panning and very low frame rate, but it's simply not true in practice or at frame rates in the double digits.

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

Again all that headroom is for MPEG-2, H.264 Blurays are typically in the low 20's with audio, many in the teens, a few in the 30'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 think you are going to be disappointed because your expectations are way too high considering the cost of this equipment. 1080p 30fps video in Bluray quality is not going happen from a sub 1k security camera.

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.

 

30fps is also not necessary, 15 fps easily halves the required bitrate and is completely adequate for the security use.

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.

Hmm ,may be I should send you very interesting "adapters"

its Ethernet over coax

here is what will happen

If I disconnect coax from adapter it WILL kill every port

(meaning every camera on network is DEAD

this is just small example

also try to put camera on RTSP and see if u like your local LAN performance.

my point still the same

keep traffic separate

its simple to do and right way to do it

No decent IT person will allow me to put IP cameras on their network

always separate subnets

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.

OK, maybe I misunderstood. So you took a 100Mbps switch, put 90Mbps workload through it, you connected your PC to a different router/switch that is Gige and connected the two switches together and the speed is about the same. I'll give you that, why would it be different, you haven't added your normal router network traffic. Is that spin, maybe, but I think it's what I brought from the start, the added traffic on the router would affect your existing router use, not the cameras.

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.

The OP does not have a gigabit switch, he already stated the model, it's 100Mbps.

That's just not true. His Asus router has a four port gigabit switch in it. Yes, his PoE switch is 100Mbps.

 

Also, the question you brought up is a connection between the switch and a PC that are each only connected through the router. What you proved is what most of us has said all along, keep the traffic between the NVR and the cameras on the switch.

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.

While other's dabble, I actually configured complex networks with $5,000 switches for massively parallel computer systems as part of my job. While different options will "work" not all will do so optimally. So far you have several people telling you to connect the cameras and NVR to the switch, one person telling you the opposite. Maybe if he shared his professional credentials as a network engineer that may help prove his case.

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...

still looking for some help since there seems to be so much debate.

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.

Blurays were made to support mpeg-2, which many movies are, plus there is the multi-channel surround sound as part of that bit rate. There are many Blurays encoded at under 20Mbps.

I was referring specifically to the video portion. The max bitrate for the disc is 48Mbps. Still you can't really use good looking low bitrate blu-rays as proof that low bitrate H.264 from a security camera is going to look good or be visually transparent. Blu-Rays can be heavily processed before they're encoded to aid compression. They don't have to be compressed real time and aren't using an encoder that has to run on a low power System on Chip. Feeding the signal directly from a camera's sensor to the compression engine is not the same. I suppose a more apt comparison would be 1920x1080 HD footage from a DSLR like the Canon 5D MkII. It shoots ~38Mbps.

 

Look at ATSC 1080i broadcast at 19Mbps MPEG-2 with DD5.1.

I'm not sure I'd use ATSC HD as a measuring stick. Much of it looks pretty poor once the scene starts changing rapidly with artifacts galore.

 

H.264 is much more advanced then MPEG-2 by most accounts you can achieve similar quality at half of MPEG-2's bitrate.

This is true if you have a good quality encoder. The quality of the encoder in the Dahua cameras is unknown. I wouldn't expect it to be anywhere near as good as an encoder like x264.

 

Netflix and iTunes both stream from 4-8Mbps for HD using H.264.

I don't have any "firsthand" viewing experience of either of these, so I can't comment here, but I hope they're better than YouTube's 1080p...

 

Ultimately, I understand that with careful tweaking of compression parameters and pre-processing the video you can visually pleasing results at the sort of bitrates that are used by the Dahua cameras. I've done it myself encoding H.264 video. Being possible doesn't mean it's happening in the Dahua cameras.