H.264 vs H264H vs H.265 encoding

[RifRaff13]

Hey guys,

I was told earlier that BI prefers H.264H encoding, and set that on my cams. A friend was telling me he thought H.265 is faster and less CPU. I am running an i7-8700 (HP EliteDesk 800 G4 with the Intel built in card) plus an Nvidia 1650. I have BI set to use NVidia NVDEC, and i see both GPUs in the perf monitor. I have used both settings being Intel+VPP (which uses the builtin Intel GPU) and NVidia and have direct to disk and BVR set on all cams.

Anyway do you guys have experience with H.265 being better encryption the H.264H? I tried it and didn't seem to make any different that i could tell but I only converted a couple cams over.

Thoughts?

Thanks
Rif

 

[wittaj]

Obviously every field of view is different and some use H265 without issue, but most of us have found H264 to be better.

This will explain H264 versus H265 a little better.

H265 in theory provides more storage as it compresses differently, but part of that compression means it macro blocks big areas of the image that it thinks isn't moving. However, it also takes more processing power of the already small CPU in the camera and that can be problematic if someone is maxing out the camera and then it stutters.

In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. Mine was less than few minutes per day. And to my eye and others that I showed clips to and just said do you like video 1 or video 2 better, everyone thought the H264 provided a better image.

The left image is H264, so all the blocks are the same size corresponding to the resolution of the camera. H265 takes areas that it doesn't think has motion and makes them into bigger blocks and in doing so lessens the resolution yet increases the CPU demand to develop these larger blocks.

In theory H265 is supposed to need half the bitrate because of the macroblocking. But if there is a lot of motion in the image, then it becomes a pixelated mess. The only way to get around that is a higher bitrate. But if you need to run the same bitrate for H265 as you do H264, then the storage savings is zero. Storage is computed based on multiplying bitrate, FPS, and resolution.



In my testing I have one camera that sees a parked car in front of my house. H265 sees that the car isn't moving, so it macroblocks the whole car and surrounding area. Then the car owner walked up to the car and got in and the motion is missed because of the macroblock being so large. Or if it catches it, because the bitrate is low, it is a pixelated mess during the critical capture point and by the time H265 adjusts to there is now motion, the ideal capture is missed.

In my case, the car is clear and defined in H264, but is blurry and soft edges in H265.

Digital zooming is never really good, but you stand a better chance with H264 rather than a large macroblocked H265. I can digital zoom on my overview camera and kinda make out the address number of the house across the street with H264, but not a chance with H265 as it macroblocked his whole house.

H265 is one of those theory things that sounds good, but reality use is much different.

As always, YMMV.

 

[tigerwillow1]

I've found that H265 gives me a little better rendition of small details when running the same bitrate as H264. I had been running H265 for a long time, experimented for a while with H264 and H264H, and went back to H265. I didn't pay attention to CPU usage.

 

[RifRaff13]

Thank you both for your explanation and rationalization. I will try it out on a couple cams that have long shots with not much motion, like a front yard that only gets small movement and see if it matters. I think your point Wittaj of using more to develop the block makes sense, and just let it process all at the same size etc, keeps it simple, and simple is better. I will still play around, but my friend was implying 265 was MUCH better and i should switch them all etc. I was not having any issues so wasn't in a hurry to do so without more input etc.

Thanks again peeps!

Rif

 

[tigerwillow1]

Nothing better than being able to experiment to see what works the best for you in your own situation.

 

[jack7]

The following may or may apply to Blue Iris:

The purpose of H.265 video compression is to reduce file size and have about the same image quality. That can result in using less disk space and lower bandwidth. It requires reducing your bitrate significantly. The resulting image quality is in the eyes of the beholder.
If you are not interested in reducing disk space or bandwidth, normally there would be no reason to use it.
Also, if distributing the H.265 video to others, it can create a problem because some video viewers do not have H.265 capability. Conversion to H.264 before sending would be required.

 

[tigerwillow1]

It requires reducing your bitrate significantly.

Why would using H.265 REQUIRE reducing the bitrate? I crank it up as the camera lets me, for maximum image quality.

 

[wittaj]

Why would using H.265 REQUIRE reducing the bitrate? I crank it up as the camera lets me, for maximum image quality.

The intent of H265 is more video compression allows for less bitrate. You can certainly crank the bitrate up, but then it starts chipping into the storage savings advantage of H265.

So in my case and field of view, even running same bitrate for H265 and H264, the H264 looked better due to macroblocking, especially when digital zooming.

So at that point they are using the same storage requirements, so I went with what my eyes and those in the house thought was a better image.

It sounds like for your field of view that H265 is better.

 

[jack7]

Why would using H.265 REQUIRE reducing the bitrate? I crank it up as the camera lets me, for maximum image quality.

I believe H.265 requires reducing bitrate if you are interested in reducing disk space or bandwidth which is the normal purpose of H.265.

 

[tigerwillow1]

Another example of me not conforming to what I'm supposed to. I'm coming from it as what setting gives the best image, damn the bitrate. With lossy encoding having to make size vs. quality tradeoffs, I can easily imagine that different encoding algorithms would work better in different situations. I often wish the camera would let me run a higher bitrate to better use the image sensor's capabilities. The resolution difference running ROI is sometimes astounding to me.

 

[spammenotinoz]

Specifics matter, previously I avoided H265 for the higher resource usage both on the BI Server and Cameras (yes the cameras were physically warmer to touch when running H265). Newer cameras don't generally suffer from this issue and I typically now use H265 on my Hikvision 4k's.
Noting;
H265 requires more CPU but less storage. H265 is also slower. So really your friend is wrong on both points.
The direct to wire (live playback feature, is H.264 only), I love this feature basically uses no CPU for playback and it's faster, really close to live footage)
H.265 isn't highly compatible, so exports, mobile playbacks require conversion.

Bitrate is basically bandwidth (amount of data per second you allow the cameras to transmit). More data = better quality

Considerations;

• More FPS, will generally lower the quality per frame to ensure all frames are transmitted (hence why 12\15fps can be ideal and why chasing fps is bad)
• Higher bitrate, requires more storage
• VBS vs CBS (varies by manufacturer, but generally Dahua cameras struggle to adapt with rapid environment changes, hence CBS is preferred)
• If you have an active scene with a lot of movement, many cameras will be maxing out the default bitrate. You can either increase the bitrate or if you are already hitting the cameras max bitrate (ie: common with Hikvision 4k, then moving to H.265 allows for double the data within the same bitrate. (In theory with 4k H.265 allows for double the quality over a smaller bitrate, compared with H.264) Arguably H.264H (high) is already pretty decent.
• You will hit a point of diminishing returns (so bets be sensible)

Here is the kicker, if you use hardware decoding you will may notice quality variances between different Intel CPUs\Nvidia GPUs, so pays to baseline without hardware decoding first.
While you want to avoid digital enlargement, typically footage recorded with hardware decoding won't fair as well. Personally, I still use hardware decoding on most cameras.
I have overlapping cameras, so kind of use a mix of settings as I haven't found perfect settings for all environments. I also tend to revisit settings from time to time.

 

[spammenotinoz]

Obviously every field of view is different and some use H265 without issue, but most of us have found H264 to be better.

This will explain H264 versus H265 a little better.

H265 in theory provides more storage as it compresses differently, but part of that compression means it macro blocks big areas of the image that it thinks isn't moving. However, it also takes more processing power of the already small CPU in the camera and that can be problematic if someone is maxing out the camera and then it stutters.

In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. Mine was less than few minutes per day. And to my eye and others that I showed clips to and just said do you like video 1 or video 2 better, everyone thought the H264 provided a better image.

The left image is H264, so all the blocks are the same size corresponding to the resolution of the camera. H265 takes areas that it doesn't think has motion and makes them into bigger blocks and in doing so lessens the resolution yet increases the CPU demand to develop these larger blocks.

In theory H265 is supposed to need half the bitrate because of the macroblocking. But if there is a lot of motion in the image, then it becomes a pixelated mess. The only way to get around that is a higher bitrate. But if you need to run the same bitrate for H265 as you do H264, then the storage savings is zero. Storage is computed based on multiplying bitrate, FPS, and resolution.

View attachment 142301

In my testing I have one camera that sees a parked car in front of my house. H265 sees that the car isn't moving, so it macroblocks the whole car and surrounding area. Then the car owner walked up to the car and got in and the motion is missed because of the macroblock being so large. Or if it catches it, because the bitrate is low, it is a pixelated mess during the critical capture point and by the time H265 adjusts to there is now motion, the ideal capture is missed.

In my case, the car is clear and defined in H264, but is blurry and soft edges in H265.

Digital zooming is never really good, but you stand a better chance with H264 rather than a large macroblocked H265. I can digital zoom on my overview camera and kinda make out the address number of the house across the street with H264, but not a chance with H265 as it macroblocked his whole house.

H265 is one of those theory things that sounds good, but reality use is much different.

As always, YMMV.

I had similar findings when using VBR, however CBS sorted that out. Dahua's in particular take too long to respond to scene changes with H.265 and VBS
What H.264 baseline did you settle on (low, standard or high)? Compression differences between H.264H and H.265 are not that high. I agree generally H.264 is better for a digital zoom.
I say generally, as with my Hikvision 4k's their bitrate is limited compared to the Dahua, so I am basically forced to use H.265 to retain high detail in high motion environments (eg: background with trees and moving leaves in the wind)

 

[wittaj]

I have played with them all. Personally I didn't see a difference among the H264 variants, so I run just plain H264.

The benefit to that as others have said is that it is still a more standard playback for when you need to send it somewhere.

But as we have seen, every field of view is different. Some get by with H265 at half the bitrate they would need for H264. Others such as mine didn't pan out that way.

 

[Parley]

Well, with the number of 4k cameras I am running on my Hikvision NVR's I have settled on H.265. I am also running mostly 12-15FPS. On a couple of cameras 16FPS. I am just trying to cut down on the bandwidth being used. By the way I have a total of 20 cameras. 16 of the cameras are running full color and the 4 license plate cameras are in black and white. Everything is steady for now.

 

[wittaj]

Well, with the number of 4k cameras I am running on my Hikvision NVR's I have settled on H.265. I am also running mostly 12-15FPS. On a couple of cameras 16FPS. I am just trying to cut down on the bandwidth being used. By the way I have a total of 20 cameras. 16 of the cameras are running full color and the 4 license plate cameras are in black and white. Everything is steady for now.

Aren't you having to run like 3 or 4 NVRs though? Just for the sake of future readers wondering why their $80 Amcrest NVR can't keep up LOL.

 

[Parley]

Aren't you having to run like 3 or 4 NVRs though? Just for the sake of future readers wondering why their $80 Amcrest NVR can't keep up LOL.

Yes, 4 NVR's. Here is a sample decoding format. 2-ch@12 MP (20 fps)/4-ch@8 MP (25 fps)/8-ch@4 MP (30 fps)/16-ch@1080p (30 fps)
Now that does not say if that is in color or black and white. Big difference with color taking up more bandwidth.

 

[Daniel15]

Why would using H.265 REQUIRE reducing the bitrate? I crank it up as the camera lets me, for maximum image quality.

You can go either way. In theory, with H.265 you can either get similar image quality with a lower bitrate compared to H.264, or higher quality at the same bitrate as you were using before.

H265 in theory provides more storage as it compresses differently, but part of that compression means it macro blocks big areas of the image that it thinks isn't moving.

H.264 uses macroblocks but H.265 uses coding tree units (CTUs) instead, which are conceptually similar but not exactly the same.

A friend was telling me he thought H.265 is faster and less CPU.

H.265 does use more processing power (so your friend is wrong about it being faster), however, both H.264 and H.265 are hardware-accelerated on modern hardware. Intel 6th generation onwards have H.265 acceleration. Android 12 pushed OEMs to use it as the default codec for video recording, so it's relatively widespread on phones now. The top video editing software (Premiere Pro, DaVinci Resolve, Final Cut) all support H.265 hardware acceleration.

Support isn't perfect though - It requires royalties to be paid, and some manufacturers don't want to pay for it. In cases like that, you'd sometimes see either older codecs like H.264, or open codecs like VP9 and AV1 being used instead.