Enabling H.265 hardware decode causes BI fault in module mfxplugin64_hw.dll

[magellan]

I reported this to BI support and haven't heard back yet, but I wanted to post here in case I'm missing something obvious or anyone else is getting tripped up by this. (it took some work to narrow it down).

• Intel hardware decode of h.265 streams appeared to be working in version 5.2.4.3 (and likely prior versions)
• Starting in 5.2.4.4, Blue Iris faults within 10 seconds if Intel h.265 hw decoding is enabled on any cameras
• Tested later versions up to 5.2.8.3 with same result
• Reverting back to 5.2.4.3 or switching all h.265 cameras to h.264 eliminates the problem
• Setup includes 15 cameras of different makes. Problem happens on multiple camera makes (eg longse and Dahua)
• CPU: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
• Latest Intel HD 4000 drivers are installed

From windows event log:

Faulting application name: BlueIris.exe, version: 5.2.8.3, time stamp: 0x5ec92f68
Faulting module name: mfxplugin64_hw.dll, version: 3.11.5.20, time stamp: 0x55688af7
Exception code: 0xc0000005

I'm fine waiting to hear from BI support, but in the meantime does anyone have any possible insights?

Thanks!

 

[IAmATeaf]

Does that CPU even support h265 hardware acceleration or can BI support it using software?

 

[magellan]

I think my cpu supports h.265.

With BI version 5.2.4.3, all the h.265 cameras show the '#' symbol in the pixels column in status view window which I think means hw decode is being used.

 

[wittaj]

That cpu does not support h.265 - it is the 6th generation and above and yours is the 3rd generation (3720). The i7 is not the generation. The generation is the first letter of the 4 digit number.

 

[magellan]

That cpu does not support h.265 - it is the 6th generation and above and yours is the 3rd generation (3720). The i7 is not the generation. The generation is the first letter of the 4 digit number.

Hmmm. I thought the status view window #'s were a reliable indicator of which cameras were using hw decode, but apparently not if h.265 isn't supported on 3rd gen cpus.

Maybe in earlier versions, BI was doing the decode in software (with no indication), but now it attempts to have the processor decode it and that causes a fault.

 

[IAmATeaf]

As above 6th gen and above.

You could try disabling hardware acceleration if you have if enabled to see if that helps?

 

[magellan]

You could try disabling hardware acceleration if you have if enabled to see if that helps?

That does work. With hardware acceleration disabled, h.265 works fine with all later BI versions.

Unfortunately, this increases my CPU load from 25% to around 33%. So it's a pick your poison sort of thing. With h.264, I get lower cpu load thanks to hw decode, but higher network load and disk usage for recording compared to h.265.

The strange thing is that as you say, it looks like my cpu doesn't support h.265, so I'm not sure how it appeared to work prior to version 5.2.4.4.

Anyhow, thanks for commenting. This was exactly the sort of obvious thing I was afraid I was missing. I didn't change anything in my setup when I upgraded, so I assumed the crash must be a BI problem rather than a "your cpu doesn't support that feature" sort of thing.

 

[IAmATeaf]

There were some h265 updates a few months ago so maybe adding support results in what you now see.

 

[wittaj]

Other than the # in BI, did you confirm in Task Manager that Hardware Acceleration was actually working in 5.2.4.3? Maybe initially it was showing it in BI but then it reverted back to none but didn't make you aware of that and now the newer version does make you aware so that you can modify a setting correctly? I have a 4th gen processor and mine did that as well - I don't think HA was actually working but didn't know it until a newer BI version.

Also, with the new versions of BI and the ability to use substreams, it will bring your cpu way down, allowing you to use h.265 for storage space purposes.

 

[magellan]

Other than the # in BI, did you confirm in Task Manager that Hardware Acceleration was actually working in 5.2.4.3?

Unfortunately, task manager only shows my NVIDIA GPU and not the Intel HD 4000, so I can't tell what it's doing. I usually can tell if hw decode is on from the change in cpu load (eg cpu goes from 55% down to 25% if decode is working) . I only have 5 out of 15 cameras that can do h265, so I probably just didn't realize they were still on sw decode.

Maybe initially it was showing it in BI but then it reverted back to none but didn't make you aware of that and now the newer version does make you aware so that you can modify a setting correctly? I have a 4th gen processor and mine did that as well - I don't think HA was actually working but didn't know it until a newer BI version.

It seems like this is exactly what happened. It would have been better if BI gave me an error rather than a fault, but at least the fault pointed me at hw decode, so it didn't take too long to figure it out.

Also, with the new versions of BI and the ability to use substreams, it will bring your cpu way down, allowing you to use h.265 for storage space purposes.

That sounds interesting. I'm running 5.2.7.12 now and it looks like this version includes substreams, so I may dig into it. Maybe it'll be the best of both worlds for those of us with older cpus. (although really, my 3rd gen cpu is doing just fine even without hw decode of h265)

 

[wittaj]

You will be amazed at the reduction. I drop off to about 11% at night and was 22% prior. Daytime would run about 40% now high teens/low 20s.

 

[manarius]

I just wanted to say that I made this change and BI also failed in the exact same manner as OP.

 

[bp2008]

Hmmm. I thought the status view window #'s were a reliable indicator of which cameras were using hw decode, but apparently not if h.265 isn't supported on 3rd gen cpus.

It is possible that Intel's hardware decoding code silently fell back to using software decoding in such a way that Blue Iris didn't know and thought hardware acceleration was working.