Dahua H.264 Bitrate Confusion

[Stereodude 0]

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!

[Securame 0]

That is just the min/max bitrates you can configure, since they have different resolutions they probably also have different bitrates by default. Cranking up the bitrate all the way up with no reason probably will not give a lot better quality, but it will surely take up a lot more HDD when recording.

[Stereodude 0]

My point was more that 8192Kbps is on the low side for visually "transparent" 1920x1080p30 or higher. For example, Blu-Ray discs that are 1920x1080p24 using H.264 can use bitrates up to 40Mbps/sec and I'm certain they're made using a much higher quality H.264/MPEG-4 AVC compression engine than the SoC in the Dahua cameras. Blu-Ray compression also doesn't have to run real time and is almost certainly done as a 2-pass VBR encode.

 

It would seem minimal compression artifacts / "transparent" video would be the target for a security camera lest they interfere with the ability to get a clean high quality image. The biggest thing the security cameras I'm looking at have going for them is the scene is primarily static (no panning, tilting, or zooming) which aids compression quite a bit. I'm just concerned that the recorded video will have compression artifacts that obscure potentially important details.

 

Is that not a problem with the 2MP and 3MP Dahua cameras?

[Stereodude 0]

Well, I guess I'll find out when the cameras I bought arrive.

[buellwinkle 0]

I have mine set at VBR and 5120k as that what ends up with the lowest lost frames with BlueIris software. Quality seems the same to me set at that or 8192k.

[StanLee2066 0]

oo

[MaxIcon 0]

I have to set my bitrate a bit lower for the Dahua 3MP to work with BI, and what I found is that I get pixelization when things change. This is especially noticeable when moving the camera around - when it moves and stops, it's very pixellated, and settles in over a few seconds to a good looking picture again.

 

This makes sense, as the more pixels change, the more data needs to be sent out, and the bigger an effect a low bitrate will have. It may be that lower bitrates are good for smaller changes in the field of view.

 

Also, the shadows tend to be quite ugly at low bitrates. When half my lawn is in shadow, the bright half looks nice and detailed, but the shadowed half is blotchy and blurry. It may be that they focus their processing on the more detailed areas, which also makes sense. I'd really like to turn this back up to full bandwidth...

[jharrell 0]

My point was more that 8192Kbps is on the low side for visually "transparent" 1920x1080p30 or higher. For example, Blu-Ray discs that are 1920x1080p24 using H.264 can use bitrates up to 40Mbps/sec and I'm certain they're made using a much higher quality H.264/MPEG-4 AVC compression engine than the SoC in the Dahua cameras.

 

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.

[Stereodude 0]

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.

[jharrell 0]

I was referring specifically to the video portion. The max bitrate for the disc is 48Mbps.

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.

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.

You can't expect low cost security cameras to compete with studio mastered Bluray either, its completely unrealistic.

I suppose a more apt comparison would be 1920x1080 HD footage from a DSLR like the Canon 5D MkII. It shoots ~38Mbps.

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

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.

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

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.

[ak357 0]

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.

You right

Broadcast quality H.264 encoder cost about $5000-$15000

I had recently tour TV Station

[Stereodude 0]

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.

[jharrell 0]

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.

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.

 

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.

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

 

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.

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.

 

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.

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.

[Stereodude 0]

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

[jharrell 0]

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.

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.

 

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

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?

[ak357 0]

 

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

 

Are u saying that BlueRay encoded at about 6Mbps ?

[jharrell 0]

Are u saying that BlueRay encoded at about 6Mbps ?

 

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

[ak357 0]

Are u saying that BlueRay encoded at about 6Mbps ?

 

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

Can someone explain to me plz

What this discussion is all about ?

I am getting confuse

[Stereodude 0]

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.

[Stereodude 0]

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.

[jharrell 0]

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.

 

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 also never said that. You seem quite apt at trying to attribute things to me that I didn't say.

 

My point was more that 8192Kbps is on the low side for visually "transparent" 1920x1080p30 or higher. For example, Blu-Ray discs that are 1920x1080p24 using H.264 can use bitrates up to 40Mbps/sec and I'm certain they're made using a much higher quality H.264/MPEG-4 AVC compression engine than the SoC in the Dahua cameras. Blu-Ray compression also doesn't have to run real time and is almost certainly done as a 2-pass VBR encode.

 

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

[Stereodude 0]

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.

[jharrell 0]

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?

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.

 

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.

 

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.