I am trying to identify how Intel's hardware Media Foundation Transform for H.264 video encoding is handling quality changes during video encoding process.
Some introductory material follows that shows that what is expected to work does not really work.
Microsoft defines H.264 encoder MFT behavior here in H.264 Video Encoder and provides a software only version of the codec in their operating systems. It is expected that vendors like Intel provide their own hardware codecs as "Certified Hardware Encoders": such encoders follow the described behavior and operating system gives them a priority as to more efficient implementation.
Intel does supply Certified Hardware Encoder for H.264 implemented in e.g mfx_mft_h264ve_64.dll (just an example, names might vary, I am referring specifically to version 126.96.36.199 in this post, the version I have as current) and this DLL along with the dependencies is Intel's implementation of such Certified Hardware Encoder.
Certified Hardware Encoder is expected to implement certain subset of functionality defined by Microsoft:
If a certified hardware encoder is present, it will generally be used instead of the inbox system encoder for Media Foundation related scenarios.
Certified encoders are required to support a certain set of ICodecAPI properties and can optionally support another set of properties.
The certification process should guarantee that the required properties are properly supported and, if an optional property is supported, that it is also properly supported.
MSDN follows that by mentioning required properties:
The following Windows 8 and Windows 8.1 ICodecAPI properties are required:
Even though Intel's encoder does mostly implement the properties, there is one aspect that does not really seem to work. From the same MSDN page:
In Windows 8, this property can be set at any time during encoding. Changes are applied starting at the next input frame.
The behavior that I see (in Windows 10 Fall Creators Update) is that Intel's Certified Hardware Encoder is ignoring quality changes during encoding. That is, the behavior I see is that encoder keeps encoding applying the initially set properties.
More to that Intel's implementation does not replicate Microsoft's own codec behavior via IMFTransform.ProcessEvent call which Intel seems to be stubbing with a no-op.
Having said all that I wonder if there is any process to still have the settings updated during encoding?
All right, the codec does not follow the requirements for Certified Hardware Encoder but maybe there a trick that still makes the desired possible.