jharrell

You obviously didn't even bother to read the paper, the formula comes from real world experimentation: "I came up with a simple framework based on some experimentation and comparing notes with some others who have been tackling the same issue." I will believe the project lead of Adobe TV Productions first hand experience over yours any day of the week. I asked you what you thought of the quality, so are you saying it's unacceptable or not, how about a straight answer? Why did you encode it with such as low CRF to get 6Mbps? You do realize CRF will smooth out bitrate right? The proper way to have tested would have been to use the Kush formula with ABR and see if you can perceive any difference.

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? So is 6Mbps ok or not considering 8Mbps is on the low side? I am confused now too.

His example from from x264 encoded the DSLR video at 6Mbps.

You've made it clear you don't care what anyone else says even IP camera manufacturers themselves. I don't know why I should try and continue to explain further because you probably continue to not care what anyone says. However the generally accepted method for determining a average bitrate is the Kush gage developed by Adobe engineer Kush Amerasinghe and explained here:http://www.adobe.com/content/dam/Adobe/en/devnet/video/articles/h264_primer/h264_primer.pdf The basic formula is [image width] x [image height] x [framerate] x [motion rank] x 0.07 = [desired bitrate] where motion rank is 1,2 or 4 for low medium and high motion content. Here is the example given: 1280 × 720 @24fps, medium motion (rank 2): 1280 × 720 × 24 × 2 × 0.07 = 3,096,576 bps = ~ 3000 kbps If the motion is high (rank 4), it’s about 6000 kbps. On the other hand, if the same clip is still usable at 5fps, and the motion is low: 1280 × 720 × 5 × 1 × 0.07 = 32,256 bps = ~ 320 kbps So I guess you know more than Adobe video engineers. Constant rate factor is going to adjust the quantization parameter based on the motion or change detected, basically compressing more the more motion is detected because it is harder to perceive compression artifacts within the motion, in effect creating a more constant bit rate. Its no surprise the bit rates are close. BTW hows that 1080p 30fps at 6Mbps, I thought it needed 40Mbps?

That is the nature of VBR and there are many scenes where the entire frame is changing such as panning shots (which fixed security cameras don't do). Dahua cameras support single pass VBR and as far as I can tell from the Ti docs the video processor can spike much higher than 8Mbps when needed in VBR. "reasonably transparent" or "a mess of compression artifacts" is binary and completely subjective I have no idea what your threshold is for something to be one or the other. The only objective comparison you made was against Bluray, that's what I went with. 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. No I am telling you a few hundred dollar security camera will not have the same image quality as equipment costing orders of magnitude more. I would not consider the video quality of broadcast 1080i or my 720p Dahua bullets at 2-4Mbps "a mess of compression", perhaps you do, and based on your comparison methods I would wager on it.

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. You can't expect low cost security cameras to compete with studio mastered Bluray either, its completely unrealistic. No not really a good comparision, the Canon 5D MkII uses Base profile, which is much worse compression then Main profile which the Dahua cameras use, they make up for this with high bit rate. It's also very unrealistic to compare a few hundred security camera to a few thousand dollar DSLR and expect comparable image quality. Here is the information on the encoder used for Dahua cameras:http://processors.wiki.ti.com/index.php/DM365_Codecs_FAQ Again you are being very unrealistic if you expect a cheap security camera to outperform broadcast television. Honestly I think this is a very good measuring stick, compared to a say a studio mastered Bluray or very expensive DSLR. 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. 30fps is also not necessary, 15 fps easily halves the required bitrate and is completely adequate for the security use.

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. Look at ATSC 1080i broadcast at 19Mbps MPEG-2 with DD5.1. H.264 is much more advanced then MPEG-2 by most accounts you can achieve similar quality at half of MPEG-2's bitrate. Netflix and iTunes both stream from 4-8Mbps for HD using H.264. I current have my 1.3MP Dahua bullets at 4Mbps at 15 fps but honestly I cannot tell a difference at 2Mbps.

That can be done with under 5 Mbits/s using H.264. Using MJPEG is way over 10Mbits/s for the same.

My guess is it downloads in realtime using the same streaming as though you where viewing. Your video is probably encoded at a 2Mbit/sec bitrate which would be exactly 2% of a 100Mbit network link. Most DVR's can download recording faster than realtime to get the file as fast as possible.

What's the bitrate of the video you are downloading?

I'll do a cleaner job on the others, I sharpied this one last night in the dark. Before: After:

The underside of mine are painted black as well, however the black does not cover all surfaces, the half circle on the top half comes from the tip of the sunshade where the black painted ended a mm or two before the edge. The left shine come from the area where the sunshade meets the body that has no black paint. I sharpied everything left white on the front face of the camera not covered by the factory black paint.

I have been setting up my Dahua bullets from my Costco NVR kit and on the cam on my driveway was getting really bad ir reflection halo's for some reason, while the others seem to look great. I think a read a post on here where someone said Q-See sharpied out the underside of the sunshade on their version (it's actually black paint). This did prompt me to try a real sharpie on the rest of the white painted face of the camera still exposed to the LED's and the results speak for themselves. Before: After: Perhaps Dahua should invest in some sharpies...

The extra stream is really quite good quality and much better on bandwidth if using cellular to view, but not having a pre-record buffer for playback is just silly. However if they allowed us to connect to the main stream as an option when the bandwidth is available would give us the pre-record buffer, and be able to use the retina display to it's fullest. Giving iOS access to the main stream is a software change, so it could be done. Any recent iOS device can easily decode multiple HD H.264 streams so it's not a issue. Still skeptical the pre-record buffer on the extra stream is a hardware limitation since the DVR can record both streams at the same time, so why can't it be recording the pre-buffer at the same time, there is no difference between a pre-record buffer and a normal one other than managing the cleanup of the unused pre-record data in a ring buffer.

The Q-See QC HD app is a rebranded iDMSS HD and is free. I know because I bought iDMSS HD in my desperation to get playback working, it has the same limitations as the Q-See versions. The only nice thing about iDMSS HD is that it is a slightly newer build than QC HD, so they polished up some of the icons and layout and it supports the E-Map feature. I am sure the Q-See version will get these features too in a future update.