Opened 18 months ago
Last modified 13 months ago
#10537 new defect
Unable to create QSV hwdevice context with onevpl and old drivers
Reported by: | Steve Browne | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | 6.1 | Keywords: | hwcontext_qsv qsv |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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.
Attachments (2)
Change History (4)
by , 18 months ago
Attachment: | onevpl-legacy-fix-6.0.patch added |
---|
comment:1 by , 13 months ago
Version: | unspecified → 6.1 |
---|
by , 13 months ago
Attachment: | onevpl-legacy-fix-6.1.1.patch added |
---|
comment:2 by , 13 months ago
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.
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.