I have observed this on two different laptops with both an Nvidia and Intel iGPU

1. GTX 980M with i7-6700HQ
2. 840M with i5-5200U

Even if this issue is only apparent on the two laptops I have tested the manual (mediasdk-man.pdf) for the minimum API version OpenCV currently supports is 1.19 (2017 R1) states

MFX_IMPL_AUTO
Find the best SDK implementation automatically. It includes either hardware-accelerated implementation on the default acceleration device or software implementation.
This value is obsolete and it is recommended to use MFX_IMPL_AUTO_ANY instead.

On two separate but related issues:

1. Is there any reason that OpenCV only supports API's from 2017 onward? For CUDA I was under the impression that OpenCV had to support API's from the last 5 years. The reason for asking is that OpenCV quick sync decoding will not work on 4th generation (API v1.17) CPU's even though it is fully supported and from my experiments on 4K h264, the Intel HD Graphics 4400 (13.97ms/frame) decoding core almost as quick as that on the GTX 980M (11.74 ms/frame).
2. Since software decoding is both much slower than the default OpenCV implementation and only available if either the Media SDK is installed or libmfxswXX.dll is present, it is likely anyone who passes CAP_INTEL_MFX to VideoCapture::open() wants to use the hardware decoder. I would also guess they would want to be informed if the hardware decoder was not available instead of being allocated a slow software decoder but I may be wrong.

I cannot comment on encoding for (1) and (2) as I have not tested this but if the same holds then wouldn't it be better to have a minimum fully supported API of 1.19, request hardware decoding always and output some information to the user if it is not available, like below?

mfxVersion ver = { {0, 1} };
mfxVersion verSupported = { {19, 1} };

res = session.Init(impl, &ver);
DBG(cout << "MFX SessionInit: " << res << endl);

if (res != MFX_ERR_NONE) {
	MSG("MFX: Hardware encoding/decodinng is not supported by your iGPU");
}

res = session.QueryIMPL(&impl);
DBG(cout << "MFX QueryIMPL: " << res << " => " << asHex(impl) << endl);

res = session.QueryVersion(&ver);
DBG(cout << "MFX QueryVersion: " << res << " => " << ver.Major << "." << ver.Minor << endl);
if (ver.Version < verSupported.Version) {
	MSG(cout << "MFX: Media SDK version " << ver.Major << "." << ver.Minor << " < " << verSupported.Major << "." << verSupported.Minor << ", all features may not be supported" << endl);
}

CUDA stuff is here for many years. So it is fine to maintain some backward compatibility.

MediaSDK backend is something new. So it is fine to target for the modern versions at first (it was added ~1 year ago, so 2027 is OK). Previous versions are not in our scope of interest currently (and also there are no OpenCV users which has MediaSDK backend working with MediaSDK previous releases).

BTW, documentation link about the flag: https://github.com/Intel-Media-SDK/MediaSDK/tree/master/doc

Thank you alalek.

@alalek

(and also there are no OpenCV users which has MediaSDK backend working with MediaSDK previous releases).

The API version affects the hardware OpenCV is run on not the version of the SDK it is compiled against, if any users have a 4th generation Intel CPU and the requested API version is left at 1.19 decoder initialization will fail even though the decoding performance on a 4K h264 file on the iGPU of a i5-4210U (low end dual core mobile CPU) is nearly as good as that on a GTX 980M and only half that on a GTX 1060. I understand that it is not in scope however adding support with the appropriate message as above "shouldn't" break anything and it would be a win for Intel vs Nvidia.

Additionally do you think it would be a good idea to force the request of the hardware decoder and give the correct output if it is not available? For me it was a little frustrating when I was performing decoding on test machines and the software decoder was selected automatically. Every time I had to either examine the CPU/iGPU usage or the libmfxxxXX.dll module which was loaded.

if any users have a 4th generation Intel CPU and the requested API version is left at 1.19 decoder initialization will fail

If you have tested it with 1.17 feel free to propose a patch with this change.

Additionally do you think it would be a good idea to force the request of the hardware decoder and give the correct output if it is not available?

Idea behind VideoCapture class is "try to read this video by all means", so it tries different backends and uses slower fallback modes if backend supports them. But we can add a property to force HW decoding for this specific backend.