// Oprogramowanie Roman Ryltsov
Even though AMD H.264 Video Encoder Media Foundation Transform (MFT) AKA AMDh264Encoder is, generally, a not so bad done piece of software, it still has a few awkward bugs to mention. At this time I am going to show this one: the video encoder transform fails to acquire synchronization on input textures. The problem comes…
Not the first, not the last. A Direct3D 11 enabled Media Foundation transfer fails to transfer sample attributes while doing the conversion. Why attributes are important in first place? Because we can associate data with samples/frames and have them passed through attached to specific frame as the conversion goes and as the data transits through…
For already years Nvidia’s H.264 video encoder Media Foundation Transform has been broken giving REGDB_E_CLASSNOTREG “Class not registered” failure in certain circumstances, like main display is not the one connected to Nvidia video adapter. As simple as this: CoInitialize(NULL); MFStartup(MF_VERSION); class __declspec(uuid(“{60F44560-5A20-4857-BFEF-D29773CB8040}”)) CFoo; // NVIDIA H.264 Encoder MFT CComPtr<IMFTransform> pTransform; const HRESULT nCoCreateInstanceResult = pTransform.CoCreateInstance(__uuidof(CFoo));…
Let us break the silence with a fresh Media Foundation bug. D3D11 WARNING: ID3D11DeviceContext::PSSetShaderResources: Resource being set to PS shader resource slot 0 is inaccessible because of a previous call to ReleaseSync or GetDC. [ STATE_SETTING WARNING #7: DEVICE_PSSETSHADERRESOURCES_HAZARD] A Direct3D 11 enabled instance of Video Processor MFT is doing something wrong with the data…
Media Foundation AAC Encoder is a pure MFT, as opposed to legacy DSP’s which are made dual DMO/MFT interfaced and presumably have higher chances for smaller artifacts. The transform is synchronous and is supposed to be simpler inside: fully passive and drives by input/output calls. Nevertheles, advertising MFT_OUTPUT_STATUS_SAMPLE_READY via IMFTransform::GetOutputStatus call, if might falsely indicate…
An attempt to copy Media Foundation attribute collection to itself results in a deadlock. Well, it’s not a good idea and a practical one to do a nonsense like this, but the implementation should be resistant to such use either, esp. avoiding the unexpected deadlock. #include “stdafx.h” #include <mfapi.h> #pragma comment(lib, “mfplat.lib”) #pragma comment(lib, “mfuuid.lib”)…
It might look weird why would someone try Direct3D mode with a DSP, which is not supposed to be Direct3D aware, but still. I am omitting the part why I even got to such scenario. The documentation says a few things about MFT_MESSAGE_SET_D3D_MANAGER: This message applies only to video transforms. The client should not send…