H.265 HA decode now works on Intel with 5.2.4.4

[Walrus]

With the latest update, H.265 HA decode appears to be working on the Intel setting. I haven't tried the other settings (DirectX or Direct3D11).

I changed a camera to H.265, and the feed froze as normal. But, when it came back, in the camera properties video tab, the HA stayed as default instead of reverting to none. (Some of the latest updates this stayed as normal too, but read on). Also the CPU and GPU stayed the same. Previous updates where I tried H.265 and it didn't work, the camera video tab HA was still default/didn't revert to none, but the CPU went up and GPU went down.

I then changed my other 2 cameras to H.265. After they came back online in BI, I am now showing 7% CPU/7% GPU for BI. With H.264H, I was at 9% CPU/9% GPU.

Try it out.

 

[Walrus]

I just tried DirectX and Direct3D11, and they don't work for H.265.

Just plain Intel does.

 

[jmhmcse]

Interesting....

2 older cameras h.264 Intel HA continues to work, and my 2 new(ish) h.265+ now running with Intel HA. GPU jumped considerably and CPU lowered slightly.

Might yet have a problem, but initial change is looking promising.

 

[fenderman]

Interesting....

2 older cameras h.264 HA continues to work, and my 2 new(ish) h.265+ now running with HA. GPU jumped considerably and CPU lowered slightly.

Might yet have a problem, but initial change is looking promising.

using h.265+ smart codec with bi will cause issues as the iframes are not constant.

 

[jmhmcse]

using h.265+ smart codec with bi will cause issues as the iframes are not constant.

correct, iframes are not constant, nor even close to set fps. The areas of BI which are most impacted by this mismatch (alert emails, pre-trigger, etc) are features I don't implement.

====

Need to redo 'tests' to compare h265+ and h.265 HA storage requirements. Went to "+" for storage savings, if HA comes close can go back to standard.

 

[fenderman]

correct, iframes are not constant, nor even close to set fps. The areas of BI which are most impacted by this mismatch (alert emails, pre-trigger, etc) are features I don't implement.

====

Need to redo 'tests' to compare h265+ and h.265 HA storage requirements. Went to "+" for storage savings, if HA comes close can go back to standard.

That is not the case. The video itself can get corrupted, this will happen exactly at the point in a video that you need. HA has no affect on storage.

 

[jmhmcse]

Would have sworn HA decreased storage requirements; oh well, my testing was done a couple of years ago....memory isn't what it used to be.

If not for continuous recording on my cameras, I would have to revert back to h.265. When clicking on thumbnail for the cameras with Intel HA and h.265+ enabled, there is a minimum 1 sec up to 8 sec lag before captured video is seen. It's an extra step to click the timeline back a few seconds to view the missing video.

Will wait and see if this becomes too irritating or revert back to no acceleration; the 50% decrease in storage would be hard to give up.

 

[fenderman]

Would have sworn HA decreased storage requirements; oh well, my testing was done a couple of years ago....memory isn't what it used to be.

If not for continuous recording on my cameras, I would have to revert back to h.265. When clicking on thumbnail for the cameras with Intel HA and h.265+ enabled, there is a minimum 1 sec up to 8 sec lag before captured video is seen. It's an extra step to click the timeline back a few seconds to view the missing video.

Will wait and see if this becomes too irritating or revert back to no acceleration; the 50% decrease in storage would be hard to give up.

It is not just a storage issue. Its a video corruption issue as another user posted above. What good is a 50 percent decrease in storage space if the video you need is corrupt or you need to wait to review video. Hard disk space is cheap. If you want to save space, try a lower bitrate.