Guia de design do MFT do dispositivo
A pilha de captura de vídeo no Windows permite uma extensão de modo de usuário na forma de DMFT. Esse é um componente de extensão por dispositivo que os IHVs fornecem, e o pipeline de captura insere como a primeira transformação, pós-captura. O DMFT recebe quadros pós-processados do dispositivo. É possível realizar outras operações de pós-processamento nos quadros dentro do DMFT. O DMFT pode receber quadros de todos os fluxos do dispositivo e expor qualquer número de fluxos de saída de acordo com a necessidade.
Este artigo descreve o design de uma extensão de dispositivo que está em execução no modo de usuário e que pode ser usada para executar o pós-processamento comum a todos os fluxos.
Terminologia
| Termo | Descrição |
|---|---|
| KS | Driver de transmissão de kernel |
| AVStream | Modelo de driver de transmissão audiovisual |
| Filter | Objeto que representa uma instância de dispositivo |
| MFT do dispositivo | Extensão de driver de captura no modo de usuário fornecida por IHVs |
| Devproxy | MF <-> AVStream marshaler |
| DTM | Device Transform Manager que gerencia devproxy e Device MFT. Representa o dispositivo no pipeline MF. |
Metas de design
Extensão do modo de usuário no filtro de dispositivo que tem a mesma duração que o Filtro de dispositivo
Aceitar qualquer número de entradas provenientes do dispositivo
Aceitar qualquer número de saídas (o requisito atual é de três fluxos: visualização, gravação e foto)
Rotear todos os controles do dispositivo para o MFT do dispositivo (que, como opção, manipula ou passa para o dispositivo)
Fazer o pós-processamento paralelo do fluxo capturado
Permitir processamento de 3A independente da taxa de quadros
Permitir que metadados de um fluxo sejam compartilhados entre outros fluxos
Acessar recursos da GPU
Acessar filas de trabalho MMCSS do MF
Acessar o MF Allocator
Simplificar a interface (semelhante ao MFT)
Manter a arquitetura interna flexível para extensibilidade de IHV/OEM
Restrições de design
Nenhuma alteração na superfície da API Capture
Compatibilidade total com versões anteriores. Por exemplo, sem regressões ao trabalhar com aplicativos e cenários herdados.
Arquitetura da pilha de captura
Este artigo descreve o suporte a uma extensão de modo de usuário em todo o filtro para o driver de captura. Esse componente tem acesso a APIs do MF, pools de threads, GPU e recursos de ISP. A ampla extensão do filtro dá flexibilidade para que se tenha qualquer número de fluxos entre ele e o filtro Ks do dispositivo. Essa flexibilidade permite a comunicação fora da faixa perfeita entre a extensão do modo de usuário e o driver que pode ser usado para metadados dedicados e fluxos de processamento 3A.
Device Transform Manager (DTM)
A pilha de captura apresenta um novo componente fornecido pelo sistema, o Device Transform Manager (DTM). Ele reside dentro de DeviceSource e gerencia Devproxy MFT e Device MFT. O DTM faz a negociação de MediaType, a propagação de amostra e todo a manipulação de eventos do MFT. Ele também expõe a interface IMFTransform para DeviceSource e outras interfaces privadas necessárias de que o DeviceSource precisa para gerenciar fluxos de dispositivo. Esse componente abstrai do pipeline o Devproxy e o MFT do dispositivo. O pipeline apenas vê o DTM como o dispositivo e os fluxos de saída do DTM como os fluxos de dispositivos.
Devproxy
Devproxy é um MFT assíncrono que realiza marshaling dos comandos e quadros de vídeo entre o driver de câmera AVStream e o Media Foundation. Ele é fornecido pelo Windows e aceita n número de saídas do driver da câmera. Além disso, ele tem os alocadores para todos os marcadores expostos pelo dispositivo.
MFT do dispositivo
O MFT do dispositivo é uma extensão do modo de usuário para o driver de captura. É um MFT assíncrono m x n. Ele é instalado no sistema com o driver de captura e é disponibilizado pelo fornecedor do driver de captura.
O número de fluxos de entrada do MFT do dispositivo deve ser igual ao número de marcadores Ks expostos pelo dispositivo. Os tipos de mídia compatíveis com os fluxos de entrada do MFT do dispositivo devem ser iguais aos tipos de mídia expostos pelos marcadores KS.
O número de fluxos de saída expostos pelo MFT do dispositivo são os fluxos vistos pelo DeviceSource e pela pilha de captura, a API de captura e os aplicativos, podendo ser um, dois ou três fluxos. As contagens de fluxo de entrada e saída do MFT do dispositivo não precisam ser as mesmas. Além disso, os fluxos de entrada e saída não precisam ter os mesmos tipos de mídia. Normalmente, têm tipos de mídia diferentes. O número de tipos de mídia também não precisa corresponder.
O primeiro marcador Ks representado no modo de usuário pelo fluxo de saída do Devproxy é associado ao primeiro fluxo de entrada do MFT do dispositivo. O segundo marcador Ks representado no modo de usuário pelo fluxo de saída do Devproxy com o segundo fluxo de entrada do MFT do dispositivo, e assim por diante.
O MFT do dispositivo recebe um ponteiro para Devproxy, dispositivo DX e ID da MF WorkQueue. Os quadros que saem do dispositivo são alimentados diretamente na entrada do MFT do dispositivo correspondente como amostras de MF. Com tudo isso, o MFT do dispositivo pode pós-processar as amostras capturadas e fornecer amostras para os marcadores de visualização, gravação e foto.
Todos os comandos e controles que vão para o dispositivo são redirecionados para o MFT do dispositivo. O MFT do dispositivo manipula os controles ou os passa para o driver por meio do Devproxy. Isso simplifica a manipulação de comandos pela pilha de driver de captura.
Visão geral funcional
Na inicialização do pipeline de captura, se houver um MFT de dispositivo para o dispositivo, o DeviceSource instanciará o DTM. Ele passa uma instância de Devproxy que representa o dispositivo para a rotina de inicialização do DTM. O DTM cocria o MFT do dispositivo e executa validações básicas. Por exemplo, verifica se o número de marcadores de saída do Devproxy é igual ao número de marcadores de entrada do MFT do dispositivo, suporte para interfaces obrigatórias e assim por diante.
O DeviceSource consulta o DTM para obter os tipos de mídia de saída permitidos. O DTM obtém isso dos marcadores de saída do MFT do dispositivo. O DeviceSource expõe o Descritor de apresentação e o Descritor de fluxo com base nessas informações para o pipeline de captura.
SourceReader usa os tipos de mídia expostos do DeviceSource e define os tipos de mídia padrão em cada fluxo. Por sua vez, o DeviceSource define os tipos de mídia padrão nos fluxos de saída do DTM. O DTM define o tipo de mídia no fluxo de saída do MFT do dispositivo usando o método SetOutputStreamState.
Quando SetOutputStreamState é chamado, o MFT do dispositivo lança uma mensagem no DTM para alterar o tipo de mídia do fluxo de entrada com base no tipo de mídia de saída selecionado e aguarda. Em resposta a essa mensagem, o DTM consulta o tipo de mídia de entrada preferencial para o fluxo de entrada do MFT do dispositivo usando GetPreferredInputStreamState. Isso define o tipo de mídia no fluxo de saída correspondente do Devproxy. Se o processo for bem-sucedido, o DTM definirá esse mesmo tipo de mídia no fluxo de entrada do MFT do dispositivo usando SetInputStreamState. Depois de receber essa chamada, o MFT do dispositivo conclui SetOutputStreamState.
O CaptureEngine seleciona fluxos individuais habilitando fluxos específicos no DeviceSource. Isso é propagado para o MFT do dispositivo pelo DTM por meio de uma chamada SetOutputStreamState. O MFT do dispositivo coloca os fluxos de saída específicos no estado solicitado. Conforme mencionado acima, o MFT do dispositivo também notifica o DTM sobre os fluxos de entrada necessários que precisam ser habilitados. Isso faz com que o DTM propague a seleção de fluxo para Devproxy. No final desse processo, todos os fluxos necessários, tanto no Devproxy como no Device MFT, ficam prontos para transmissão.
SourceReader inicia o DeviceSource quando CaptureEngine chama ReadSample. Por sua vez, o DeviceSource inicia o DTM enviando as mensagens MFT_MESSAGE_NOTIFY_BEGIN_STREAMING e MFT_MESSAGE_NOTIFY_START_OF_STREAM, que indicam o início do pipeline. O DTM inicia o Devproxy e o MFT do dispositivo propagando as mensagens MFT_MESSAGE_NOTIFY_BEGIN_STREAMING e MFT_MESSAGE_NOTIFY_START_OF_STREAM.
Observação
Aloque os recursos necessários ao iniciar a transmissão em vez da inicialização do MFT do dispositivo.
O DTM chama SetOutputStreamState nas saídas do MFT do dispositivo com o parâmetro de estado de transmissão. O MFT do dispositivo inicia a transmissão nesses fluxos de saída. O DTM inicia a transmissão nos fluxos de saída Devproxy que têm um tipo de mídia válido definido. O Devproxy aloca as amostras e as pesquisa no dispositivo. Essas amostras são alimentadas no MFT do dispositivo no marcador de entrada relevante. O MFT do dispositivo processa essas amostras e faz a saída para DeviceSource. A partir do DeviceSource, os exemplos circulam por meio do SourceReader para o CaptureEngine.
O CaptureEngine interrompe os fluxos individuais desabilitando-os por meio de uma interface interna no DeviceSource. Isso se transforma em um fluxo de saída específico desabilitado no MFT do dispositivo por meio de SetOutputStreamState. Por sua vez, o MFT do dispositivo pode solicitar que fluxos de entrada específicos sejam desabilitados por meio do evento METransformInputStreamStateChanged. O DTM propaga isso para os fluxos Devproxy correspondentes.
Desde que o próprio MFT do dispositivo esteja no estado de transmissão, ele pode solicitar que qualquer fluxo de entrada faça a transição para qualquer DeviceStreamState válido. Por exemplo, ele pode enviá-lo para DeviceStreamState_Stop ou DeviceStreamState_Run ou DeviceStreamState_Pause, e assim por diante, sem afetar outros fluxos.
No entanto, a transição do fluxo de saída é controlada pelo pipeline de captura. Por exemplo, os fluxos de visualização, registro e foto são habilitados ou desabilitados pelo pipeline de captura. Mesmo quando as saídas estão desabilitadas, um fluxo de entrada ainda pode estar transmitindo, contanto que o próprio MFT do dispositivo esteja no estado de transmissão.
Duração do MFT do dispositivo
O MFT do dispositivo é carregado após a criação do Filtro KS. Ele é descarregado antes que o Filtro KS seja fechado.
De uma perspectiva do pipeline, quando o DeviceSource é criado, o MFT do dispositivo é criado e, quando o DeviceSource é desligado, o MFT do dispositivo é desligado de forma síncrona.
Para auxiliar no desligamento, o MFT do dispositivo deve aceitar a interface IMFShutdown. Depois que Device MFT->Shutdown é chamado, qualquer outra chamada de interface para o MFT do dispositivo deverá retornar um erro MF_E_SHUTDOWN.
Tipo de memória
Os quadros podem ser capturados em buffers de memória do sistema ou buffers de memória DX, de acordo com a preferência do driver da câmera. Qualquer buffer proveniente do driver da câmera é alimentado diretamente no MFT do dispositivo para processamento adicional.
O Devproxy aloca os buffers com base na preferência do driver. Precisamos que o MFT do dispositivo use APIs do MF Allocator para alocar as amostras necessárias de seus marcadores de saída para transformações fora do lugar.
Alteração de tipo de mídia durante a transmissão
Os clientes do SourceReader podem ver os tipos de mídia expostos pelos fluxos de saída do MFT do dispositivo como tipos de mídia com suporte nativo. Quando o tipo de mídia nativo é alterado, o SourceReader envia chamadas de notificação de tipo de mídia para o MFT do dispositivo por meio de DeviceSource. É responsabilidade do MFT do dispositivo liberar todas as amostras pendentes da fila desse fluxo e alternar para o novo tipo de mídia nesse fluxo em tempo hábil. Se houver necessidade de alterar o tipo de mídia de entrada, o novo tipo de mídia de entrada atual deverá ser o primeiro. O DTM usa o tipo de mídia atual do fluxo de entrada do MFT do dispositivo e o define nos fluxos de saída do Devproxy e na entrada do MFT do dispositivo depois de cada alteração de tipo de mídia nativo.
Alteração de tipo de mídia de entrada no MFT do dispositivo
Por ser um MFT m x n, pode haver repercussões nos tipos de mídia do marcador de transmissão de entrada e na alteração de estado quando os tipos de mídia ou o estado do marcador de transmissão de saída são alterados. Quando especificamente ocorrem as seguintes alterações:
Alterações de tipo de mídia de saída
Quando um aplicativo altera o tipo de mídia nativo, ele se distribui pela pilha de captura no MFT do dispositivo como uma alteração de tipo de mídia do marcador de saída.
Quando o tipo de mídia de saída é alterado, ele pode disparar uma alteração de tipo de mídia de entrada. Por exemplo, suponha que todos os marcadores de saída estejam transmitindo a 720p. Isso resulta em transmissão da câmera em 720p. Em seguida, suponha que o fluxo de registro altere seu tipo de mídia nativo para 1080p. Nesse caso, um dos fluxos de entrada do MFT do dispositivo que estava buscando dados para o fluxo de registro teria de alterar seu tipo de mídia.
O marcador de saída está desabilitado
- Quando um aplicativo desabilita uma das saídas do MFT do dispositivo depois que a mesma entrada é compartilhada por mais de uma saída, para fins de otimização, a entrada pode precisar alterar o tipo de mídia. Por exemplo, se um fluxo de saída de 1080p for interrompido e todos os outros fluxos, que compartilham uma entrada, estiverem transmitindo a 720p, o fluxo de entrada deverá alterar seu tipo de mídia para 720p para economizar energia e melhorar o desempenho.
O DTM manipula as notificações METransformInputStreamStateChanged do MFT do dispositivo para alterar o tipo de mídia e o estado na entrada do MFT do dispositivo e na saída do Devproxy nessas condições.
Tipos de mídia de saída preferenciais do MFT do dispositivo
Recomendamos que o MFT do dispositivo produza tipos de mídia de saída usando o formato NV12. YUY2 é a melhor alternativa seguinte. Os tipos de mídia MJPEG e RGB não são recomendados.
Liberar MFT do dispositivo
São necessários dois tipos de liberação durante o gerenciamento do MFT do dispositivo:
Liberação global
Liberação de todo o MFT do dispositivo. Isso normalmente acontece quando o DTM está prestes a enviar uma mensagem de interrupção de transmissão para o MFT do dispositivo.
Espera-se que o MFT do dispositivo remova todas as amostras de suas filas de entrada e saída e retorne de forma síncrona.
O MFT do dispositivo não deve solicitar uma nova entrada ou enviar notificação sobre a nova saída disponível.
Liberação local
- Liberação específica do marcador de saída. Isso normalmente acontece quando um fluxo é interrompido.
Todos os eventos que foram lançados antes da liberação são descartados pelo Gerenciador de MFT do dispositivo. Após a liberação, o MFT do dispositivo redefine sua contagem interna de acompanhamento METransformHaveOutput.
Drenagem do MFT do dispositivo
O MFT do dispositivo não recebe uma mensagem de drenagem separada, pois não há necessidade de drenagem em uma fonte de captura dinâmica.
Gatilho de foto
Nesse modelo, em vez de enviar os gatilhos de início e parada da sequência de fotos diretamente para o driver, eles são redirecionados para o MFT do dispositivo. O dispositivo MFT manipula o gatilho ou o encaminha para o driver da câmera, depende da necessidade.
Inicialização a quente
O DeviceSource tenta iniciar a quente um fluxo de saída específico fazendo a transição do fluxo para o estado de pausa. Por sua vez, o DTM chama o método IMFDeviceTransform::SetOutputStreamState no MFT do dispositivo para fazer a transição de um fluxo de saída específico para o estado de pausa. Isso faz com que o fluxo de entrada correspondente seja colocado em pausa. Isso é obtido pelo MFT do dispositivo com a solicitação de METransformInputStreamStateChanged para DTM e manipulação do método IMFDeviceTransform::SetInputStreamState.
Sequência de fotos variável
Com essa arquitetura, a sequência de fotos é implementada com o driver de dispositivo de câmera e o MFT do dispositivo, o que reduz bastante a complexidade do driver de dispositivo de câmera. Os gatilhos de sequência de fotos de início e parada são enviados para o MFT do dispositivo e manipulam a sequência de fotos com mais facilidade.
Confirmação por foto
O MFT do dispositivo permite a confirmação por foto pela interface IMFCapturePhotoConfirmation. O pipeline recupera essa interface por meio do método IMFGetService::GetService.
Metadados
O Devproxy consulta o driver para o tamanho do buffer de metadados e aloca a memória para metadados. Os metadados provenientes do driver ainda são definidos pelo Devproxy na amostra. O MFT do dispositivo consome os metadados da amostra. Os metadados podem ser transmitidos com a amostra por meio de seu fluxo de saída ou usados para seu pós-processamento.
Como o MFT do dispositivo permite qualquer número de entradas, um marcador de entrada dedicado pode ser usado apenas para metadados ou metadados fora da faixa. O tipo de mídia para esse marcador é personalizado, e o driver decide o tamanho e o número de buffers.
Esse fluxo de metadados é exposto além do DTM. O fluxo pode ser colocado no estado de transmissão quando o MFT do dispositivo começa a transmitir. Por exemplo, quando os fluxos de saída são selecionados para transmissão, o MFT do dispositivo pode solicitar que o DTM inicie um ou mais fluxos de vídeo e também o fluxo de metadados, usando o evento METransformInputStreamStateChanged.
Observação: Não há necessidade de que o número de marcadores de entrada corresponda ao número de marcadores de saída neste modelo. Pode haver um marcador separado dedicado para metadados ou 3A.
Manipulação de eventos do Device Transform Manager (DTM)
Os eventos do Device Transform Manager são definidos nos seguintes artigos de referência:
Interface IMFDeviceTransform
A interface IMFDeviceTransform é definida para interagir com o MFT do dispositivo. Esta interface facilita o gerenciamento de m entradas e n saídas do MFT do dispositivo. Juntamente com outras interfaces, o MFT do dispositivo deve implementar essa interface.
Propagação geral de eventos
Quando ocorre um evento no Devproxy (ou dentro do dispositivo), ele precisaser propagado para o MFT do dispositivo e para o DeviceSource.
Requisitos do MFT do dispositivo
Requisitos de interface
Os MFTs de dispositivo devem aceitar as seguintes interfaces:
-
Isso permite que todos os ksproperties, eventos e métodos passem pelo MFT do dispositivo. Assim, o MFT do dispositivo pode manipular essas chamadas de funções dentro do MFT do dispositivo ou apenas encaminhá-las para o driver. Se ele manipular os métodos KsEvent, o MFT do dispositivo precisará executar as seguintes etapas:
Se o MFT do dispositivo manipular qualquer evento KSEVENT_TYPE_ONESHOT, ele duplicará o identificador quando receber KSEVENT_TYPE_ENABLE.
Quando terminar de definir ou gerar o evento, ele chamará CloseHandle no identificador duplicado.
Se o MFT do dispositivo manipular eventos não KSEVENT_TYPE_ONESHOT, ele deverá duplicar o identificador quando receber KSEVENT_TYPE_ENABLE e chamar CloseHandle no identificador duplicado quando o evento ks estiver desabilitado, chamando a função KsEvent com o primeiro parâmetro (ID do evento ks) e o segundo parâmetro (duração do evento) definidos como zero. Os dados e a duração do evento são válidos. Os dados do evento identificam exclusivamente um evento ks específico.
Se o MFT do dispositivo manipular eventos não KSEVENT_TYPE_ONESHOT, ele deverá duplicar o identificador quando receber KSEVENT_TYPE_ENABLE e chamar CloseHandle nos identificadores duplicados quando os eventos ks forem desabilitados, chamando a função KsEvent com todos os parâmetros definidos como zero.
Requisitos de notificação
Os MFTs do dispositivo devem usar as seguintes mensagens para informar o DTM sobre a disponibilidade de amostras, qualquer alteração de estado do fluxo de entrada, entre outros.
Requisitos de thread
O MFT do dispositivo não deve criar seus próprios threads. Em vez disso, ele deve usar filas de trabalho do Media Foundation, que são alocadas com base na ID passada para o DMFT por meio da interface IMFRealTimeClientEx. Isso serve para garantir que todos os threads em execução no MFT do dispositivo tenham a prioridade correta em que o pipeline de captura está sendo executado e evitar inversões de prioridade de thread.
Requisitos de InputStream
Contagem de fluxos
- O número de fluxos de entrada no MFT do dispositivo deve ser o mesmo que o número de fluxos compatíveis com o driver.
MediaTypes
O número de tipos de mídia e os tipos de mídia reais compatíveis com a entrada do MFT do dispositivo devem corresponder ao número e aos tipos de mídia compatíveis com o driver.
O número só poderá ser diferente se os tipos de mídia compatíveis com a entrada do MFT do dispositivo forem um subconjunto dos tipos de mídia compatíveis com o driver.
Os tipos de mídia compatíveis com o driver e a entrada do MFT do dispositivo podem ser tipos de mídia padrão ou personalizados.
Como registrar o MFT do dispositivo
O INF do dispositivo de câmera deve ter a seguinte entrada de interface de dispositivo que especifica CLSID do CoClass do MFT do dispositivo.
[CaptureAvstrm.Device.NTarm.Interfaces]
AddInterface = %KSCATEGORY_VIDEO_CAMERA%, %Capture.FilterDescBack%, Capture.FilterBack
[Capture.FilterBack]
AddReg = Capture.FilterBack.AddReg, PinNames.AddReg
[Capture.FilterBack.AddReg]
HKR,,FriendlyName,,%Capture.FilterDescBack%
HKR,,CameraDeviceMftClsid,,%CameraDeviceMFT.Clsid%
Essas entradas INF resultam na inserção das seguintes chaves do Registro:
Observação
Este é apenas um exemplo (não a regkey real)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{E5323777-F976-4f5b-9B55-B94699C46E44}\##?#USB#VID_045E&PID_075D&MI_00#8&23C3DB65&0&0000#{E5323777-F976-4f5b-9B55-B94699C46E44}\#GLOBAL\Device Parameters]
"CLSID"="{17CCA71B-ECD7-11D0-B908-00A0C9223196}"
"FriendlyName"="USB Video Device"
"CameraDeviceMftClsid"="{3456A71B-ECD7-11D0-B908-00A0C9223196}"<<< Device MFT CoClass ID >>>
Encadeamento de MFT do dispositivo
O MFT do dispositivo é o mecanismo de plug-in de modo de usuário recomendado para IHVs e OEMs para estender a funcionalidade de câmera no Windows.
Antes do Windows 10, versão 1703, o pipeline da câmera aceitava apenas um plug-in de extensão DMFT.
A partir do Windows 10, versão 1703, o pipeline de câmera do Windows aceita uma cadeia opcional de DMFTs com até dois DMFTs.
A partir do Windows 11, versão 22H2, o pipeline de câmera do Windows aceita uma cadeia opcional de DMFTs com até quatro DMFTs.
Isso traz mais flexibilidade para OEMs e IHVs fornecerem valor agregado na forma de fluxos de câmera de pós-processamento. Por exemplo, um dispositivo pode usar o PDMFT junto com um DMFT IHV e um DMFT OEM.
A figura a seguir ilustra a arquitetura que envolve uma cadeia de DMFTs.
As amostras de captura fluem do driver da câmera para o DevProxy e, em seguida, passam pelas cadeias DMFT. Cada DMFT na cadeia tem a chance de processar a amostra. Se o DMFT não quiser processar a amostra, ele pode atuar como uma passagem, ou seja, basta passar a amostra para o próximo DMFT.
Para controles como KsProperty, a chamada sobe no fluxo: o último DMFT na cadeia recebe a chamada primeiro. A chamada pode ser manipulada lá mesmo ou ser passada para o DMFT anterior na cadeia.
Os erros são propagados do DMFT para o DTM e, em seguida, para os aplicativos. Para DMFTs IHV/OEM, qualquer DMFT que não instanciar será um erro fatal para o DTM.
Requisitos aplicáveis a DMFTs:
A contagem de marcadores de entrada do DMFT deve corresponder à contagem de marcadores de saída do DMFT anterior. Caso contrário, o DTM falhará durante a inicialização. No entanto, as contagens de marcadores de entrada e saída do mesmo DMFT não precisam corresponder.
O DMFT precisa aceitar interfaces – IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl e IMFMediaEventGenerator. Talvez seja necessário aceitar IMFTransform se houver o MFT0 configurado ou se o próximo DMFT na cadeia exigir suporte a IMFTransform.
Em sistemas de 64 bits que não usam o Frame Server, os DMFTs de 32 bits e 64 bits devem ser registrados. Considerando que uma câmera USB pode ser conectada a um sistema arbitrário, para câmeras USB "externas" (ou fora da caixa de entrada), o fornecedor da câmera USB deve fornecer DMFTs de 32 bits e 64 bits.
Configurar a cadeia do DMFT
Como opção, um dispositivo de câmera pode fornecer um objeto DMFT COM em uma DLL usando um arquivo INF personalizado que usa seções da caixa de entrada USBVideo.INF.
Na seção "Interface AddReg" do arquivo .INF, especifique os CLSIDs do DMFT adicionando a seguinte entrada do Registro:
CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%
Conforme mostrado nas configurações de INF da amostra abaixo (substitua %Dmft0.CLSID% e % Dmft1.CLSID% pelas cadeias de caracteres CLSID reais que você está usando para seus DMFTs), há no máximo 2 CLSIDs permitidos no Windows 10, versão 1703. O primeiro é o mais próximo do DevProxy, enquanto o último é o último DMFT na cadeia.
O CLSID DMFT da plataforma é {3D096DDE-8971-4AD5-98F9-C74F56492630}.
Alguns exemplos de configurações de CameraDeviceMftCLSIDChain:
Sem IHV/OEM DMFT ou DMFT da plataforma
- CameraDeviceMftCLSIDChain = "" (ou não é necessário especificar essa entrada do Registro)
DMFT de IHV/OEM
- CameraDeviceMftCLSIDChain = %Dmft.CLSID%
Plataforma DMFT <-> DMFT de IHV/OEM
CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%
Veja aqui uma captura de tela da chave do Registro de resultado para uma câmera USB com DMFT de plataforma e um DMFT (com GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) na cadeia.
IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Observação
CameraDeviceMftCLSIDChain pode ter no máximo 2 CLSIDs.
Se CameraDeviceMftCLSIDChain estiver configurado, as configurações herdadas de CameraDeviceMftCLSID serão ignoradas pelo DTM.
Se CameraDeviceMftCLSIDChain não estiver configurado e o CameraDeviceMftCLSID herdado estiver configurado, a cadeia será semelhante a (se sua câmera USB e compatível com o DMFT da plataforma e o DMFT da plataforma estiver habilitado) DevProxy <–> DMFT da plataforma <–> DMFT do OEM/IHV ou (se a câmera não permitir DMFT da plataforma ou o DMFT da plataforma estiver desabilitado) DevProxy <–> DMFT do OEM/IHV.
Exemplo de configurações de arquivo INF:
[USBVideo.Interface.AddReg]
HKR,,CLSID,,%ProxyVCap.CLSID%
HKR,,FriendlyName,,%USBVideo.DeviceDesc%
HKR,,RTCFlags,0x00010001,0x00000010
HKR,,EnablePlatformDmft,0x00010001,0x00000001
HKR,,DisablePlatformDmftFeatures,0x00010001,0x00000001
HKR,,CameraDeviceMftCLSIDChain, 0x00010000,%Dmft0.CLSID%,%Dmft1.CLSID%
Objeto Com e registro de MFT de MFTs do dispositivo
Em vez de registrar o objeto COM do driver globalmente, o objeto COM do driver é registrado na chave do dispositivo. Isso permite o registro COM do MFT de dentro do contêiner e impede que chaves do Registro globais sejam criadas, preservando assim o isolamento do pacote de driver. Os MFTs também são registrados na chave do dispositivo por motivos semelhantes.
Alterações de INF do driver
Após a instalação do driver de dispositivo, o INF agora deve fazer todos os registros de objeto COM e MFT na chave do dispositivo. Os registros MFT e COM devem ser alterados conforme mostrado aqui:
Registros de MFT
| Antes | Após |
|---|---|
| INF AddReg: HKCR, MediaFoundation\Transforms\{clsid}\... |
Software de dispositivo por instância INF AddReg: HKR, MediaFoundation\Transforms\{clsid}\... |
| Local do Registro: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Locais de Registro: software key\MediaFoundation\Transforms\{clsid}\... |
Registros de COM
No Windows 26100 e posterior, todos os registros COM para MFTs de dispositivo devem usar diretivas AddComServer/AddComClass no INF. Um exemplo de sintaxe é mostrado aqui:
[AvsCamera.COM]
AddComServer = AvsCameraMFT,,AvsCamera.COMInstall
[AvsCamera.COMInstall]
ServerType = 1; in-proc
ServerBinary = %13%\AvsCameraDMFT.dll
AddComClass = %DMFT.CLSID%,, AvsCamera.COMClassInstall
[AvsCamera.COMClassInstall]
ThreadingModel = Both
Description = %AvsCamera.ComServerDescription%
As versões anteriores do registro de COM do MFT do dispositivo usavam AddReg para instalar manualmente a classe COM.
| Antes | Após |
|---|---|
| INF AddReg: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Software de dispositivo por instância INF AddReg: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\... |
A sintaxe INF para diferenciação com base na versão do sistema operacional pode ser encontrada em Combinar extensões de plataforma com versões do sistema operacional. A partir do Windows 11 25300, o INF deve estar em conformidade com essas novas chaves do Registro. As versões mais antigas do sistema operacional usam as chaves de registro tradicionais para fins de compatibilidade. O INF deve configurar essas chaves do Registro no local antigo em builds do sistema operacional mais antigos e criar as novas chaves em seu novo local para builds de sistema operacional mais recentes. Por exemplo, para um registro MFT em um build mais antigo, o INF cria a chave na seguinte entrada do Registro:
HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\
Para um registro MFT em um novo build, o INF criará a chave na seguinte entrada do Registro:
**software key**\MediaFoundation\Transforms\{clsid}\
Essa entrada define onde a chave de software representa a chave de software de um dispositivo.
Para obter mais informações, consulte Abrir a chave de software de um dispositivo.
Um exemplo de sintaxe de como direcionar diferentes versões do sistema operacional é mostrado aqui:
[Manufacturer]
%Msft% = Msft, NTamd64,NTamd64.10.0...25300
; -------------- ;
; Models Section ;
; -------------- ;
; Targets old builds
[Msft.NTamd64]
%DeviceDesc% = ExampleDDInstall_Old, ExampleHardwareId
[ExampleDDInstall_Old]
AddReg = MFT_Registration_Old
[MFT_Registration_Old]
; INF work for older build here
; Windows 10 build with build number equal to or greater than 25300
[msft.ntamd64.10.0...25300]
%DeviceDesc% = ExampleDDInstall_New, ExampleHardwareId
[ExampleDDInstall_new]
AddReg = MFT_Registration_new
[MFT_Registration_new]
; INF work for newer build here