Compatibilidad con MFT de dispositivo (perfil de cámara V2)
En escenarios en los que los IHV/OEM necesitan publicar perfiles de cámara en función de la información del entorno de ejecución (por ejemplo, un conjunto de controladores usados para varias SKU que usan sensores diferentes), los controladores de cámara deben implementar un MFT de dispositivo para publicar los perfiles de cámara.
Durante la llamada InitializeTransform de Device MFT, DMFT puede publicar perfiles de cámara proporcionando la interfaz IMFSensorProfileCollection a través del atributo siguiente:
// MF_DEVICEMFT_SENSORPROFILE_COLLECTION
// Data type: IUnknown
// IMFSensorProfileCollection interface that SGT Factory can provide to indicate new
// profiles available to the SG generation.
cpp_quote("EXTERN_GUID(MF_DEVICEMFT_SENSORPROFILE_COLLECTION, 0x36EBDC44, 0xB12C, 0x441B, 0x89, 0xF4, 0x08, 0xB2, 0xF4, 0x1A, 0x9C, 0xFC );")
Este atributo debe establecerse en el almacén de atributos del IMFTransform proporcionado al DMFT a través del atributo MF_DEVICEMFT_CONNECTED_FILTER_KSCONTROL.
En el siguiente fragmento de código se muestra cómo el DMFT durante el método InitializeTransform puede proporcionar un nuevo perfil de cámara.
Para este ejemplo, vamos a realizar algunas suposiciones:
Esta es una cámara de 4 pines.
Pin 0 – Capture, Pin 1 – Preview, Pin 2 – Photo and Pin 3 – IR stream.
IFACEMETHODIMP
SampleDMFT::InitializeTransform(
_In_ IMFAttributes *pAttributes
)
{
ComPtr<IMFTransform> spTransform;
ComPtr<IMFAttributes> spAttributes;
ComPtr<IMFSensorProfileCollection> spProfileCollection;
ComPtr<IMFSensorProfile> spProfile;
if (nullptr == pAttributes)
{
return E_INVALIDARG;
}
RETURN_IF_FAILED (pAttributes->GetUnknown(MF_DEVICEMFT_CONNECTED_FILTER_KSCONTROL,
IID_PPV_ARGS(&spTransform)));
RETURN_IF_FAILED (spTransform->GetAttributes(&spAttributes));
// Create an empty collection...
RETURN_IF_FAILED (MFCreateSensorProfileCollection(&spProfileCollection));
// Create various profiles we want to publish.
// For the legacy profile, we don't want to expose the IR stream since
// legacy apps will not be able to consume it.
RETURN_IF_FAILED (MFCreateSensorProfile(KSCAMERAPROFILE_Legacy, 0, nullptr, &spProfile));
RETURN_IF_FAILED (spProfile->AddProfileFilter(0, L"((RES==;FRT<=30,1;SUT==))"));
RETURN_IF_FAILED (spProfile->AddProfileFilter(1, L"((RES==;FRT<=30,1;SUT==))"));
RETURN_IF_FAILED (spProfile->AddProfileFilter(2, L"((RES==;FRT<=30,1;SUT==))"));
RETURN_IF_FAILED (spProfile->AddProfileFilter(3, L"(!)"));
RETURN_IF_FAILED (spProfileCollection->AddProfile(spProfile));
spProfile = nullptr;
// For the High Frame Rate recording profile, we only support 60fps or
// higher on the record pin and any on the preview (since preview only
// exposes 30fps).
RETURN_IF_FAILED (MFCreateSensorProfile(KSCAMERAPROFILE_HighFrameRate, 0, nullptr, &spProfile));
RETURN_IF_FAILED (spProfile->AddProfileFilter(0, L"((RES==;FRT>=60,1;SUT==))"));
RETURN_IF_FAILED (spProfile->AddProfileFilter(1, L"((RES==;FRT==;SUT==))"));
RETURN_IF_FAILED (spProfile->AddProfileFilter(2, L"(!)"));
RETURN_IF_FAILED (spProfile->AddProfileFilter(3, L"(!)"));
RETURN_IF_FAILED (spProfileCollection->AddProfile(spProfile));
spProfile = nullptr;
// For the Face Auth, we can handle any media type on the preview but we
// want to remove the photo and record pins and allow the IR pin to only
// expose one media type: VGA@60fps with L8.
RETURN_IF_FAILED (MFCreateSensorProfile(KSCAMERAPROFILE_FaceAuth_Mode, 0, nullptr, &spProfile));
RETURN_IF_FAILED (spProfile->AddProfileFilter(0, L"(!)"));
RETURN_IF_FAILED (spProfile->AddProfileFilter(1, L"((RES==;FRT==;SUT==))"));
RETURN_IF_FAILED (spProfile->AddProfileFilter(2, L"(!)"));
RETURN_IF_FAILED (spProfile->AddProfileFilter(3, L"((RES==640,480;FRT==60,1;SUT==L8))"));
RETURN_IF_FAILED (spProfileCollection->AddProfile(spProfile));
spProfile = nullptr;
// Set the profile collection to the attribute store of the IMFTransform.
RETURN_IF_FAILED (spAttributes->SetUnknown(MF_DEVICEMFT_SENSORPROFILE_COLLECTION,
spProfileCollection));
// ... Reset of the InitializeTransform logic...
}
El MF_DEVICEMFT_SENSORPROFILE_COLLECTION debe publicarse en el almacén de atributos de IMFTransform conectado antes de que el método InitializeTransform() devuelva.
DMFT encadenado
En el escenario en el que se encadenan varias DMFT dentro del origen del dispositivo, la DMFT responsable de publicar el perfil de cámara debe estar configurada por el IHV/OEM como la primera transformación de la cadena después de DevProxy o Platform DMFT si platform DMFT está habilitado.
Por ejemplo, se admite la publicación de perfiles de cámara desde IHV/OEM DMFT1 en las siguientes topologías:
En topología 1 y 2, solo DMFT1 puede publicar perfiles de cámara. Se omitirá cualquier perfil de cámara publicado por DMFT2.
M-in, N-out Device MFT
Una de las características admitidas por las MFT de dispositivo es la capacidad de tomar un número arbitrario de flujos de entrada y exponer un número diferente de flujos de salida.
Dado que la lógica del perfil requiere el identificador de anclaje para identificar la información del filtro de perfil, la asignación de patillas debe ser coherente.
El IMFSensorProfileCollection publicado por el MFT del dispositivo debe usar la numeración pin basada en el pin de salida de DMFT. El identificador de pin en este caso debe coincidir con el atributo MF_DEVICESTREAM_STREAM_ID presentado en el almacén de atributos del pin de salida.
Para evitar posibles colisiones de identificadores de patillas, DMFT DEBE quitar el MF_DEVICESTREAM_TRANSFORM_STREAM_ID. La MF_DEVICESTREAM_TRANSFORM_STREAM_ID solo la presenta DevProxy y solo tiene sentido en el contexto de DevProxy. En el caso de una dmft de entrada y salida, el MF_DEVICESTREAM_TRANSFORM_STREAM_ID no está definido.