H.264 vs H.265 in blue iris

jeffseine

jeffseine

n3wb
Sep 14, 2017
13
5
I just put together a blue iris server for the first time. I tried searching about this, but I need some clarification.

From what I understand, the following is true. Blue iris runs h.264 with hardware acceleration, and it runs h.265 without hardware acceleration.

So if that is true, I would want to run h.264 to keep my CPU lower at the expense of disk space. If I value hard drive space more, I would use h.265 at the expense of the cpu.

How much hard drive space does h.265 save over h.264?

Are there any other reasons why I would pick one or the other?

Is there a chance in the future blue iris would support hardware acceleration for h.265?

Thanks in advance.
 
In theory H.265 offers similar quality at half the bandwidth/disk usage. But that is hard to verify and I don't recall anyone doing good tests to see if it holds up.

Blue Iris has already tried to support hardware acceleration for H.265, but so far failed due to driver problems or something. There is a strong chance it will support hardware acceleration for H.265 in the future, though I don't think anybody knows how it will compare to H.264 acceleration in terms of how many megapixels per second it can handle and what the CPU usage will be like. H.264 acceleration from an i7-8700K can handle around 1500 MP/s with H.264 hardware acceleration but I'm guessing probably less with H.265 when that becomes available.
 
  • Like
Reactions: iseeker, jeffseine and fenderman
So is this why I feel my Dahua ZE H.265 cams don't seem as good as I **think** they should in BI? When accessing the camera directly I feel there is a noticeable difference in nighttime shots, where the camera itself illuminates the dark patches better than what I see in BI. I am utilizing the Generic RTSP H.264/H.265 driver in BI.
 
fastsvo said:
So is this why I feel my Dahua ZE H.265 cams don't seem as good as I **think** they should in BI? When accessing the camera directly I feel there is a noticeable difference in nighttime shots, where the camera itself illuminates the dark patches better than what I see in BI. I am utilizing the Generic RTSP H.264/H.265 driver in BI.
Click to expand...
when using direct to disk and you should be, blue iris is not altering the feed, regardless of whether you are using 264 or 265. Also note that even if 265 ha was supported it would only be for 6th gen intel and up. Ensure smart codec is off in the camera.
 
  • Like
Reactions: fastsvo
For whatever little it is worth, and I know this isn't a perfect scientific way to do this, but here is the BVR storage data for 3 cameras at the same location for very nearly the same time period (7/1 to 7/31 - give or take a few hours on each one), direct to disk. Was wanting to stay under my data cap, but will raise FY to max resolution for the remainder of this month since I ended the month 400GB under the limit.

BY: H.265 1920x1080 VBR4 2FPS Iframe: 4 (indoor, essentially zero movement): 15.6GB
FY: H.265 2304x1296 VBR6 2FPS Iframe: 4 (outdoor, lots of movement, street/cars): 324 GB
IN: H.264H 1280x960 VBR4 2FPS Iframe: 4 (indoors, no movement, light changes twice daily): 50GB

I recall when I was installing the 5MP camera, the actual data rate was noticeably lower with H.265, not 50% but maybe 35%, and in the case where there is very little movement I think the impact is potentially greater for H.265 than even H.264.


Open to testing different things with these cameras, or measuring a different way, but the router itself doesn't have built-in per-IP bandwidth consumption metrics.
 
Yes, my CO router/firewall automatically connects via OpenVPN connection to ASUS router at remote location so Blue Iris (in CO) can directly record all my cameras, these happen to be in IL. That provider in IL is the one with the 1GB limit so I watch the data usage more closely.

I wonder if the VBR = 6 and the extreme difference between the motion levels explains the difference (324GB vs 16GB !?), because the resolution difference should effectively be 2MP vs 3MP.

*Edit, I think that H.265 camera was being re-encoded to H.264 at BI, flipped it to continuous and direct-to-disk, and turned off "H.264 HW decode". Will update when I have more days of data for the one that was changed, might be better apples-to-oranges comparison (3MP H.264 vs 5MP H.265 over x-days, same camera etc)
 
Last edited:
  • Like
Reactions: fenderman
Update (for whatever it is worth) : since changing the configuration in BI from re-encoding the 3MP stream into H.264 I can provide the following "take it with a grain of salt" data points:

** the data transmission includes 3 cameras, two were left unchanged, and I don't report the file sizes for those BVR files in any of the comparison details, but I cant easily separate them from the data transmission number.

H.264-encode, 2304x1296 VBR6 2FPS Iframe: 4
================================================
File sizes range: 8.30GB to 9.13GB average: 8.58GB
Data transmission (from remote router traffic logs): ~17.4GB

H.265, 2592x1944 VBR6 2FPS Iframe: 4
================================================
File sizes range: 6.32GB to 6.39GB average: 6.36GB
Data transmission (from remote router traffic logs): ~14.7GB

Resolution was increased from 2.99MP to 5.04MP (168%)
File size still shrank by about 25%

I don't think the 50% quoted by bp2008 is entirely out of the question. I will say looking at snapshot images grabbed in BI the H.265 has more apparent artifacts than the recoded H.264 does for the same patch of sidewalk, but idk how to tell if those artifacts are in the video (from compression) or are caused by BI open/snapshot.
 
Last edited:
Apologies for bringing up an old thread but wanted to ask if there's any update regarding BI and H265 support. One of my cameras supports H265 but when I switch to it from H264 I notice the recordings become choppy.

My server is a :
Dell Optiplex 3020 SFF i5-4590
and the recording is set '' directly to disk''.
Any particular settings I need to tweak?
 
H.265 hardware acceleration works now, but your CPU is too old to use it. H.265 still is slower to decode than H.264, and that is likely the reason your recordings aren't as smooth that way.

H.265 isn't a game changing improvement over H.264 anyway. Nice to have if your computer can handle it, but not required.
 
  • Like
Reactions: SouthernYankee, gwminor48 and gtj
Great insight. That's all I needed to know.
Many thanks!
 
May I also ask about H264H and H264B profiles. In what way are they any different than standard H264? Should I bother experimenting with them?
 
H264H means "high profile" and "H264B" means "base profile". High profile can use more advanced encoding features. Whether those are used or not, and how they might affect video quality and CPU usage, I cannot say.

The developer of Blue Iris doesn't recommend H264H, but I use it anyway and generally don't have problems.
 
  • Like
Reactions: SouthernYankee, gwminor48 and gtj
bp2008 said:
H264H means "high profile" and "H264B" means "base profile". High profile can use more advanced encoding features. Whether those are used or not, and how they might affect video quality and CPU usage, I cannot say.

The developer of Blue Iris doesn't recommend H264H, but I use it anyway and generally don't have problems.
Click to expand...
Thank you very much. I'll stay with standard H264.
 
You must log in or register to reply here.
Top Bottom