h264 or h265
- Thread starter joshwah
- Start date
Ssayer
BIT Beta Team
A lot of posts/threads on this H265 has more compression so....
f1restarter
Pulling my weight
I have followed the advice around here to run 264.
Bandwidth issues are seldom the case + Disk space is cheap and the savings are not huge.
265 also introduces more compression artifacts. I have noticed that many members that seek advice for poor image quality is always told to go for 264
Bandwidth issues are seldom the case + Disk space is cheap and the savings are not huge.
265 also introduces more compression artifacts. I have noticed that many members that seek advice for poor image quality is always told to go for 264
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. That can be problematic for digital zooming with H265.
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 in other areas like FPS and then it stutters.
Further some cameras can handle H265 better than others, even if the camera "claims" to support it.
In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. My savings were 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 in those larger blocks yet increases the camera 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 essentially zero.
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 and not something we recommend, but you stand a better chance of some digital zoom 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.
Some people have a field of view or goals that allow H265 to be sufficient for their needs.
As always, YMMV.
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. That can be problematic for digital zooming with H265.
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 in other areas like FPS and then it stutters.
Further some cameras can handle H265 better than others, even if the camera "claims" to support it.
In theory it is supposed to need 30% less storage than H264, but most of us have found it isn't that much. My savings were 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 in those larger blocks yet increases the camera 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 essentially zero.
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 and not something we recommend, but you stand a better chance of some digital zoom 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.
Some people have a field of view or goals that allow H265 to be sufficient for their needs.
As always, YMMV.
Last edited:
About half my cams are running H.265 and about half H.264. Whenever I really take time and focus on studying the image quality of a camera, I can usually find places where quality isn't as good as I want. Usually in shadowed and highly detailed areas like the inner branches of a tree. So I switch between H.264 and H.265, and I tend to find that H.265 adds a bit more blur, while H.264 adds a bit more sharp-edged artifacts ("noise" essentially). There is no clear win in many cases, even though H.265 has the technical advantage on paper. It always boils down to how well the encoder works, and not all encoders are created equal. H.264 encoders have been around many years longer than H.265 encoders, so engineers have had more time to understand and tune them closer to perfection, which largely negates the advantages of H.265.
Eh, no. That is like saying that distance is based on multiplying your vehicle's speed, tire diameter, and horsepower. But everyone knows distance is just the result of multiplying speed and time. Storage requirements are the same way, it is bit rate multiplied by time.
And yet the calculator that you put in the wiki has you put in resolution, FPS, and bitrate to calculate hard drive space....
Regardless, your statement proves what else I said - if the bitrate is the same for H264 and H265, then the storage requirements are the same, so go with the one that produces the better image.
Calculating Required Hard Drive Size
Calculate the hard drive (HDD) size necessary for your surveillance camera system. Pinpoint amount of days of recordings & more. Save & view results later.
Last edited:
Technically the resolution and FPS are not used in the storage calculation. They are only used to select a predefined bit rate from a table. But I can see how it could be confusing the way the UI presents the inputs.And yet the calculator that you put in the wiki has you put in resolution, FPS, and bitrate to calculate hard drive space....
Absolutely.
That is the next poll
But yes most find the CBR produces a better overall image as some field of views result in the camera not being able to up the bitrate fast enough with VBR to get quality captures.
I don't know if the cameras encoder is underpowered or if it's BI/intel video decoder being slow at decoding.
I am testing a 300$ Hikvision NVR and it's so incredibly smooth with all 8 streams.
I love the smell of thread hijacking in the morning.
Last edited:
From what I've gathered, h.265 encoding is usually junk in cheaper cameras, and added just so they can claim it has it.
Do your own testing. I tried h.265 and motion was absolute garbage. The moving object and the background it just passed through would be a pixelated mess, with everything stationary and unchanging looking great.
Perhaps some higher end cameras have good h.265 encoding, but I have no experience with a high end camera so can't say with any authority.
h.265 saves disk space, but disk space is cheap. 14 TB for $135.
All that said, I do prefer h.265 when collecting pre-recorded video content. The image is better per MB than h.264.
Do your own testing. I tried h.265 and motion was absolute garbage. The moving object and the background it just passed through would be a pixelated mess, with everything stationary and unchanging looking great.
Perhaps some higher end cameras have good h.265 encoding, but I have no experience with a high end camera so can't say with any authority.
h.265 saves disk space, but disk space is cheap. 14 TB for $135.
All that said, I do prefer h.265 when collecting pre-recorded video content. The image is better per MB than h.264.
tmxv4128
Pulling my weight
Just now I just did a quick experiment with a T180 camera I have facing the street. In the static picture you can see a street sign that is 68' from the camera. In the attached video, I zoomed in on the sign in FCP. First with all settings the same except for H.264.H compression, and the second set for H.265. It is apparent to me that H.264.H provides the better quality.
Attachments
I may, or may not have PMS, for those in the know.a.k.a torrenting
Don't need kids watching commercials for the few shows I've approved of.
That has been my experience as well. I have found H264 and 12-15FPS to be the sweet spot in terms of maximizing each frame.
No the + is a smart code and should be avoided unless using the dame brand NVR and camera.
H264 in some cameras have H264, H264M H264B, and H264H for main, base, and high.
For many people H264H produces the best. But it comes down to your equipment, eyes, and monitor. For most H264 as that has been around the longest and most widely used.
264 vs 264B vs 264H ?
Have a new cam (2831) and noticed that I now have the B and H options. But after spending some time searching, I'm not finding anything clear that describes the differences in these 3 formats. Anyone able to comment on the primary attributes of each...compared to the other? (Good, Better, Best)??
I thought H meant High as the programmer was on marijuana when he did compressing coding for H264H.No the + is a smart code and should be avoided unless using the dame brand NVR and camera.
H264 in some cameras have H264, H264M H264B, and H264H for main, base, and high.
For many people H264H produces the best. But it comes down to your equipment, eyes, and monitor. For most H264 as that has been around the longest and most widely used.
264 vs 264B vs 264H ?
Have a new cam (2831) and noticed that I now have the B and H options. But after spending some time searching, I'm not finding anything clear that describes the differences in these 3 formats. Anyone able to comment on the primary attributes of each...compared to the other? (Good, Better, Best)??ipcamtalk.com
tigerwillow1
Known around here
Another factor is bitrate, a factor if you're close to maxing out what the recording device can handle.
I'd need to know the bitrates used for each image to form my own conclusion. From my own casual testing, I decided that it's pretty much a wash between 264 and 265, with 265 running at a lower bitrate. I suspect that other factors are the content of the image, frame rate, and I-frame interval. None of my cameras come very close to maximizing the capability of the sensor and optics, and evidenced by the quality improvement in ROI areas. After reading through this thread I'm thinking the image quality is limited by sub-par compression code and/or available CPU horsepower that won't allow a higher bitrate.