imsdk creators block ability to use the latest imsdk implementations and processor features

[OTorg]

BRCParamMultiplier parameter was added since imsdk 1.3.
Applications developed with lower sdk version know nothing about BRCParamMultiplier and therefore wiil always stumble on MFX_ERR_NOT_ENOUGH_BUFFER if real encoder version returns BRCParamMultiplier >= 2 from GetVideoParam call (I saw such situation with my own eyes, furthermore, no one of imsdk 1.7 samples apply out-BRCParamMultiplier).
Such approach to new imsdk features introduction forces application developers to modify mfx_dispatch to restrict libmfx*.dll usage - libmfx*.dll must have exactly the same vesrion as application's MFX_VERSION_MAJOR/MFX_VERSION_MINOR, not greater.
So features/performance of the latest processors and imsdk implementations (avx2, iris, etc) are ignored thereby (till new sdk study -> application adaptation -> rebuild -> tests -> release).
It is sad. Especially from such a famous and high-quality producer as Intel.

[Anthony_P_Intel]

Hi,

Any application can/should be created to the lowest API feature set that it requires.  In you example, applications that initialized the API at level less than 1.3 should not expect to be able to use features of 1.3 or newer.  If the application does desire a feature in newer API, it can initialize the API with the greater value.  There is no need to modify mfx_dispatch.  The application should provide mfx_Init with the minimum API for the features it needs, and it should not use (or expect support for) any features in higher API.

The implemenations of libmfx*.dll are compatible with lower-level APIs.  For example, the current MediaSDK 2013 R2 libmfxsw*.dll supports API 1.0 thru 1.7, and applications written to use only API 1.0 (and call mfx_Init with 1.0) will run just as well (or better) than they did on earier implemenations.

An application written with API less than 1.3 should not beable to see/user BRCParamMultiplier parameter at all, and no API 1.3 usage should result in the usage of any bitrate requiring BRCParamMultiplier >= 2.

Were you able to see MFX_ERR_NOT_ENOUGH_BUFFER when the application initialized with API less than 1.3 and uses only input parameters (levels,profiles, etc.) that are part of the older API?  

[OTorg]

You've written the correct architectural approach. And I absolutely agree with it. But in practice, we can see the discrepancy.
I attach a simple application that demonstrates my words.

When it is executed with libmfxsw32.dll shipped with imsdk 1.1:
BufferSizeInKB = 11718; reserved[7].hiword = 0

When it is executed with libmfxsw32.dll shipped with imsdk 1.7:
BufferSizeInKB = 5859; reserved[7].hiword = 2

[Anthony_P_Intel]

I see. Thank you for the description!

In this case, it does look like our library is assuming 1.7 behavior even when initialized with 1.1 and I'd agree that is a bug.  Thank you for reporting.

[OTorg]

ok

[OTorg]

Issue was not fixed in imsdk 1.8 (Intel Media SDK 2014 for Clients).

When brcparammultiplier.exe is executed with libmfxsw32.dll shipped with imsdk 1.8:
BufferSizeInKB = 5859; reserved[7].hiword = 2