Unable to create QSV hwdevice context with onevpl and old drivers

[Steve Browne]

Summary of the bug:
After switching over to building with onevpl some systems with older Intel Windows drivers will fail to create hwdevice context. One system in particular has an Intel HD Graphics 4400 driver 20.19.15.4531 from 9/29/2016. There was also another system that had drivers dated to 2018, but unfortunately that system is no longer available so I can't give more driver details than that.

Upgrading the drivers will resolve it, but we have customers that are already working and we don't want them to have to upgrade drivers to get the software working again after an upgrade.

Basically MFXCreateSession fails for some of these older drivers. I've modified the code to fallback to the else clause version of *_create_mfx_session which uses MFXInitEx instead and it resolves the issue.

How to reproduce:

AVBufferRef* ctx= nullptr;
AVDictionary* dict = nullptr;
av_dict_set(&dict, "child_device_type", "d3d11va", 0);
int result = ::av_hwdevice_ctx_create(&ctx, AV_HWDEVICE_TYPE_QSV, "auto", dict, 0);

I'll post the patch I have. It's just a quick and dirty fix of moving the else version of the functions out of the ifdefs and calling it from the else clause and in case of failure when creating from a loader. I don't bother cleaning up the loader and just let it get attached to the QSVSession as if it was successfully used.

[Steve Browne]

I just upgraded to ffmpeg 6.1.1 and saw this again on an Intel HD Graphics 630 driver 26.20.100.7262 from 9/25/2019. This is a Core i5-7500. I'll post another updated patch. I had previously posted a ticket with Intel on their onevpl repo here ​https://github.com/intel/libvpl/issues/105. They said these platforms aren't supported and there are no plans to support them so it seems like the best bet is to workaround it by falling back to the old libmfx which is what I do in the patch and it's pretty simple.

[v0lt]

Upgrading the drivers will resolve it, but we have customers that are already working and we don't want them to have to upgrade drivers to get the software working again after an upgrade.

Some people don't want to update a driver (a simple one-time task), and many others don't want to support legacy APIs (a complex, long-term task). The first one looks irrational.