Guia de design de MFT do dispositivo

A pilha de captura de vídeo do Windows oferece suporte a uma extensão no modo de usuário conhecida como DMFT. Esse é um componente de extensão para cada dispositivo que os IHVs fornecem, e o pipeline de captura insere como a primeira transformação após captura. O DMFT recebe quadros pós-processados do dispositivo. Operações adicionais de pós-processamento nos quadros podem ser realizadas dentro do DMFT. O DMFT pode receber quadros de todos os fluxos do dispositivo e pode expor qualquer número de fluxos de saída de acordo com o requisito.

Este artigo descreve o design de uma extensão em todo o dispositivo em execução no modo de usuário que pode ser usada para executar o pós-processamento comum a todos os fluxos.

Terminologia

Metas de design

• Extensão de modo de usuário que abrange todo o filtro do dispositivo e tem o mesmo tempo de vida que o Filtro de Dispositivo

• Dá suporte a qualquer número de entradas provenientes do dispositivo

• Dá suporte a qualquer número de saídas (o requisito atual é de três fluxos: visualização, registro e foto)

• Roteia todos os controles de dispositivo para o Dispositivo MFT (que opcionalmente manipula ou passa para o dispositivo)

• Pós-processamento paralelo do fluxo capturado

• Permitir o processamento 3A independente da taxa de quadros

• Permitir que metadados de um fluxo sejam compartilhados entre outros fluxos

• Acesso aos recursos de GPU

• Acesso a filas de trabalho do MF MMCSS

• Acesso ao Alocador de MF

• Interface simples (semelhante ao MFT)

• Arquitetura interna flexível para extensibilidade de IHV/OEM

Restrições de design

• Nenhuma alteração na superfície da API de Captura

• Compatibilidade completa com versões anteriores. Por exemplo, nenhuma regressão ao trabalhar com aplicativos e cenários herdados.

Arquitetura de pilha de captura

Este artigo descreve o suporte para uma extensão de modo de usuário abrangendo todo o filtro para o driver de captura. Esse componente tem acesso a APIs de MF, pools de threads, GPU e recursos ISP. A extensão de largura do filtro fornece a flexibilidade de ter qualquer número de fluxos entre si e o filtro KS do dispositivo. Essa flexibilidade permite a comunicação perfeita fora da banda entre a extensão do modo de usuário e o driver que pode ser usado para metadados dedicados e fluxos de processamento 3A.

DTM (Gerenciador de Transformações de Dispositivo)

A pilha de captura introduz um novo componente fornecido pelo sistema, o Gerenciador de Transformação do Dispositivo (DTM). Isso está localizado no DeviceSource e gerencia o MFT do Devproxy e o MFT do Dispositivo. A DTM faz a negociação de MediaType, a propagação de amostra e toda a manipulação de eventos MFT. Ele também expõe a interface IMFTransform para DeviceSource e outras interfaces privadas necessárias que o DeviceSource precisa para gerenciar fluxos de dispositivo. Esse componente abstrai o Devproxy e o Device MFT do pipeline. O pipeline apenas vê o DTM como sendo o dispositivo e os fluxos originários do DTM como fluxos de dispositivo.

Devproxy

Devproxy é um MFT assíncrono que organiza os comandos e quadros de vídeo entre o driver de câmera AVStream e o Media Foundation. Isso é fornecido pelo Windows e dá suporte a n número de saídas do driver de câmera. Além disso, possui os alocadores para todos os pinos expostos pelo dispositivo.

MFT do dispositivo

O MFT do dispositivo é uma extensão de 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 é fornecido pelo fornecedor do driver de captura.

O número de fluxos de entrada do Dispositivo MFT deve ser o mesmo que o número de pinos Ks expostos pelo dispositivo. Os tipos de mídia compatíveis com os fluxos de entrada do Dispositivo MFT devem ser iguais aos tipos de mídia expostos pelos pinos KS.

O número de fluxos de saída expostos pelo MFT do dispositivo são os fluxos vistos pelo DeviceSource, pela pilha de captura, pela API de captura e pelos aplicativos, podendo ser um, dois ou três fluxos. As contagens de fluxo de entrada e saída do Dispositivo MFT 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 e normalmente têm tipos de mídia diferentes. O número de tipos de mídia também não precisa corresponder.

O primeiro Pin Ks representado no modo de usuário pelo fluxo de saída do Devproxy é associado ao primeiro fluxo de entrada do Dispositivo MFT, o segundo Pin Ks representado no modo de usuário pelo fluxo de saída do Devproxy com o segundo fluxo de entrada do Dispositivo MFT e assim por diante.

O MFT do dispositivo recebe um ponteiro para Devproxy, dispositivo DX e ID do WorkQueue do MF. Os quadros que saem do dispositivo são transferidos diretamente para a entrada do MFT do dispositivo correspondente como amostras de MF. Com tudo isso, o Dispositivo MFT pode processar posteriormente as amostras capturadas e fornecer amostras para os pinos de pré-visualização, gravação e foto.

Todos os comandos e controles que vão para o dispositivo são redirecionados para o Dispositivo MFT. O MFT do dispositivo manipula os controles ou os passa para o driver por meio do Devproxy. Isso simplifica o tratamento de comandos pela pilha do driver de captura.

Visão geral funcional

Na inicialização do pipeline de captura, se houver um dispositivo MFT para o dispositivo, o DeviceSource instancia o DTM. Ele passa uma instância do Devproxy que representa o dispositivo para a rotina de inicialização do DTM. O DTM cocria o Dispositivo MFT e executa validações básicas. Por exemplo, verifica se o número de pinos de saída de Devproxy é o mesmo que o número de pinos de entrada do Dispositivo MFT, o suporte para interfaces obrigatórias e assim por diante.

O DeviceSource consulta o DTM para obter os tipos de mídia de saída com suporte. O DTM obtém isso dos pinos de saída do Dispositivo MFT. O DeviceSource expõe o Descritor de Apresentação e o Descritor de Fluxo com base nessas informações no 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, 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 dispositivo MFT usando o método SetOutputStreamState .

Quando SetOutputStreamState é chamado, o Dispositivo MFT posta uma mensagem no DTM para alterar o mediatype do fluxo de entrada com base no mediatype 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 dispositivo MFT usando GetPreferredInputStreamState. Isso define o tipo de mídia no fluxo de saída correspondente de Devproxy. Se isso for bem-sucedido, o DTM definirá esse mesmo tipo de mídia no fluxo de entrada do dispositivo MFT usando SetInputStreamState. Depois de receber essa chamada, o Dispositivo MFT conclui SetOutputStreamState.

O CaptureEngine seleciona fluxos individuais habilitando fluxos específicos no DeviceSource. Isso é propagado para o Dispositivo MFT por 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 Dispositivo MFT também notifica o DTM sobre os fluxos de entrada necessários que precisam ser habilitados. Isso resulta em DTM propagando a seleção de fluxo para Devproxy. No final desse processo, todos os fluxos necessários, no Devproxy e no Dispositivo MFT, estão prontos para serem transmitidos.

SourceReader inicia o DeviceSource quando CaptureEngine chama ReadSample. Por sua vez, o DeviceSource inicia o DTM enviando mensagens MFT_MESSAGE_NOTIFY_BEGIN_STREAMING e MFT_MESSAGE_NOTIFY_START_OF_STREAM indicando o início do pipeline. O DTM inicia Devproxy e Device MFT propagando as mensagens MFT_MESSAGE_NOTIFY_BEGIN_STREAMING e MFT_MESSAGE_NOTIFY_START_OF_STREAM.

O DTM chama SetOutputStreamState nas saídas do Dispositivo MFT com o parâmetro de estado de streaming. O MFT do dispositivo inicia o streaming nesses fluxos de saída. A DTM inicia o streaming nos fluxos de saída do Devproxy que têm a mediatype válida definida. O Devproxy aloca os exemplos e os busca do dispositivo. Esses exemplos são enviados ao MFT do dispositivo no pino de entrada relevante. O MFT do dispositivo processa esses exemplos e fornece a saída para DeviceSource. A partir do DeviceSource, as amostras fluem através do SourceReader até o CaptureEngine.

O CaptureEngine interrompe fluxos específicos desativando-os por meio de uma interface interna no DeviceSource. Essa tradução resulta na desativação do fluxo de saída específico no dispositivo MFT por meio de SetOutputStreamState. Por sua vez, o Dispositivo MFT pode solicitar a desabilitação de fluxos de entrada específicos por meio do evento METransformInputStreamStateChanged . A DTM propaga isso para fluxos de Devproxy correspondentes.

Desde que o próprio dispositivo MFT esteja no estado de streaming, ele pode solicitar qualquer fluxo de entrada para fazer a transição para qualquer um dos DeviceStreamState válidos. 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 processo 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 sendo transmitido desde que o próprio dispositivo MFT esteja no estado de streaming.

Tempo de vida do dispositivo MFT

O MFT do dispositivo é carregado depois que o Filtro KS é criado. Ele é descarregado/desativado antes do Filtro KS ser fechado.

De uma perspectiva de pipeline, quando o DeviceSource é criado, o Dispositivo MFT é criado e, quando o DeviceSource é desligado, o Dispositivo MFT é desligado de forma síncrona.

Para dar suporte ao desligamento, o MFT do dispositivo deve dar suporte à interface IMFShutdown . Depois que Device MFT-Shutdown> for chamado, qualquer outra chamada de interface para o Device MFT deve 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 de câmera. Qualquer buffer que sai do driver da câmera é diretamente alimentado no MFT do dispositivo para processamento adicional.

O Devproxy aloca os buffers com base na preferência do driver. Exigimos que o Dispositivo MFT use APIs de alocador MF para alocar os exemplos necessários para seus pinos de saída para transformações não insubstituíveis.

Alteração de tipo de mídia durante o streaming

Os clientes do SourceReader podem ver os tipos de mídia expostos pelos fluxos de saída do dispositivo MFT como tipos de mídia com suporte nativo. Quando o tipo de mídia nativo é alterado, o SourceReader envia chamadas de notificação do tipo de mídia para o Dispositivo MFT por meio do DeviceSource. É responsabilidade do dispositivo MFT liberar todos os exemplos pendentes da fila desse fluxo e alternar para o novo tipo de mídia nesse fluxo em tempo hábil. Se houver uma necessidade de alterar o tipo de mídia de entrada, ele deverá alterar o tipo de mídia de entrada atual para esse. O DTM obtém o tipo de mídia atual do fluxo de entrada do Dispositivo MFT e o define nos fluxos de saída do Devproxy e na entrada do MFT do dispositivo após cada alteração de tipo de mídia nativo.

Alteração de tipo de mídia de entrada no MFT do dispositivo

Como esse é um MFT m x n , pode haver repercussões nos tipos de mídia e na alteração de estado do pino de streaming de entrada quando os tipos de mídia ou o estado do pino de streaming de saída são alterados. Especificamente quando as seguintes alterações ocorrem:

• Alterações no tipo de mídia de saída

  • Quando um aplicativo altera o tipo de mídia nativo, ele é propagado através da pilha de captura no Dispositivo MFT como uma alteração no tipo de mídia do pino 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 pinos de saída estejam sendo transmitidos a 720p. Isso resulta em streaming da câmera em 720p. Em seguida, suponha que o fluxo de registros altere seu tipo de mídia nativo para 1080p. Nesse caso, um dos fluxos de entrada MFT do dispositivo que buscava dados para o fluxo de registro teria que alterar seu tipo de mídia.

• O pino de saída está desabilitado

  • Quando um aplicativo desativa uma das saídas do Dispositivo MFT, ao compartilhar a mesma entrada com mais de uma saída, para otimização, pode ser necessário alterar o tipo de mídia da entrada. Por exemplo, se um fluxo de saída de 1080p parar e todos os outros fluxos, compartilhando 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 Dispositivo MFT para alterar o tipo de mídia e o estado na entrada do Dispositivo MFT e na saída de Devproxy sob essas condições.

Tipos de mídia de saída preferenciais do dispositivo MFT

Recomendamos que o Dispositivo MFT produza tipos de mídia de saída usando o formato NV12. YUY2 é a próxima melhor alternativa. Tipos de mídia MJPEG e RGB não são recomendados.

Liberar MFT do dispositivo

Dois tipos de liberação são necessários durante o gerenciamento do dispositivo MFT:

• Liberação global

  • Liberação de MFT em escala do dispositivo Isso normalmente acontece quando o DTM está prestes a enviar uma mensagem de interrupção de streaming para o Dispositivo MFT.

  • Espera-se que o MFT do dispositivo descarte 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 na nova saída disponível.

• Liberação local

  • Limpeza específica do pino de saída. Isso normalmente acontece quando um fluxo é interrompido.

Todos os eventos que foram postados antes do esvaziamento são descartados pelo Gerenciador de Dispositivo MFT. Após a liberação, o Dispositivo MFT redefine sua contagem interna de acompanhamento METransformHaveOutput .

Dreno do dispositivo MFT

O dispositivo MFT não receberá uma mensagem de dreno separada, pois não há necessidade de esvaziamento em uma fonte de captura dinâmica.

Disparador de foto

Nesse modelo, em vez de enviar diretamente para o driver os gatilhos para iniciar e parar a sequência de fotos, eles são redirecionados para o Dispositivo MFT. O MFT do dispositivo manipula o gatilho ou o encaminha para o driver da câmera, conforme necessário.

Início quente

DeviceSource tenta iniciar um fluxo de saída específico transicionando o fluxo para o estado de pausa. Por sua vez, o DTM chama o método IMFDeviceTransform::SetOutputStreamState no Dispositivo MFT para fazer a transição de um fluxo de saída específico para pausar o estado. Isso resulta no fluxo de entrada correspondente a ser colocado em pausa. Isso é obtido pelo Dispositivo MFT solicitando METransformInputStreamStateChanged para DTM e tratando o método IMFDeviceTransform::SetInputStreamState .

Sequência de fotos variáveis

Com essa arquitetura, a sequência de fotos é implementada com o driver do dispositivo de câmera e o Dispositivo MFT, reduzindo consideravelmente a complexidade do driver do dispositivo de câmera. Os gatilhos de início e parada da sequência de fotos são enviados para o MFT do Dispositivo, facilitando a manipulação da sequência de fotos.

Confirmação de foto

O MFT do dispositivo dá suporte à confirmação de fotos por meio da interface IMFCapturePhotoConfirmation . O pipeline recupera essa interface por meio do método IMFGetService::GetService .

Metadados

O Devproxy consulta o driver quanto ao tamanho do buffer de metadados e aloca a memória para metadados. Os metadados provenientes do driver são definidos por Devproxy na amostra. O MFT do dispositivo consome os metadados da amostra. Os metadados podem ser passados com o exemplo por meio de seu fluxo de saída ou usados para seu pós-processamento.

Com o Dispositivo MFT dando suporte a qualquer número de entradas, um pin de entrada dedicado pode ser usado apenas para metadados ou metadados fora de banda. O tipo de mídia para esse pin é 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 streaming quando o Dispositivo MFT inicia o streaming. Por exemplo, quando os fluxos de saída são selecionados para streaming, o Dispositivo MFT pode solicitar que o DTM inicie um ou mais fluxos de vídeo e o fluxo de metadados também, usando o evento METransformInputStreamStateChanged .

Observação: não há nenhum requisito para que o número de pinos de entrada corresponda ao número de pinos de saída neste modelo. Pode haver um pin separado dedicado para metadados ou 3A.

Manipulação de eventos do DTM (Gerenciador de Transformações de Dispositivo)

Os eventos do Gerenciador de Transformação de Dispositivos são definidos nos seguintes artigos de referência:

• METransformFlushInputStream

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformNeedInput

Interface IMFDeviceTransform

A interface IMFDeviceTransform é definida para interagir com o MFT do dispositivo. Essa interface facilita o gerenciamento das entradas m e do MFT de dispositivo de saída n. Juntamente com outras interfaces, o Dispositivo MFT deve implementar essa interface.

Propagação geral de eventos

Quando um evento ocorre no Devproxy (ou dentro do dispositivo), precisamos propagar isso para o Dispositivo MFT e para o DeviceSource.

Requisitos de MFT do dispositivo

Requisitos de interface

Os MFTs do dispositivo devem dar suporte às seguintes interfaces:

• IMFDeviceTransform

• IKsControl

  • Isso permite que todos os ksproperties, eventos e métodos percorram o MFT do dispositivo. Isso fornece ao Dispositivo MFT a capacidade de lidar com essas chamadas de funções dentro do Dispositivo MFT ou apenas encaminhá-las para o driver. No caso em que ele manipula os métodos KsEvent, o MFT do dispositivo precisa executar as seguintes etapas:

    • Se o Dispositivo MFT manipular qualquer evento KSEVENT_TYPE_ONESHOT, ele duplicará o handle quando receber KSEVENT_TYPE_ENABLE.

    • Quando terminar de definir ou gerar o evento, ele chamará CloseHandle no identificador duplicado.

    • Se o Dispositivo MFT manipular eventos que não sejam KSEVENT_TYPE_ONESHOT, ele deverá duplicar o identificador ao receber KSEVENT_TYPE_ENABLE e chamar CloseHandle no identificador duplicado quando o evento ks for desabilitado, chamando a função KsEvent com o primeiro parâmetro (ID do evento ks) e o segundo parâmetro (comprimento 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 Dispositivo MFT manipular eventos que não sejam do tipo KSEVENT_TYPE_ONESHOT, ele deverá duplicar a alça quando receber KSEVENT_TYPE_ENABLE e deverá chamar CloseHandle nas alças duplicadas quando os eventos ks forem desabilitados, chamando a função KsEvent com todos os parâmetros definidos como zero.

• IMFRealTimeClientEx

• IMFMediaEventGenerator

• IMFShutdown

• IMFSampleAllocatorControl

Requisitos de notificação

Os MFTs do dispositivo devem usar as seguintes mensagens para informar a DTM sobre a disponibilidade de exemplos, qualquer alteração de estado do fluxo de entrada e assim por diante.

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

Requisitos de linha de execução

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 no ID passado para o DMFT por meio da interface IMFRealTimeClientEx. Isso serve para garantir que todos os threads em execução no Dispositivo MFT obtenham a prioridade correta em que o pipeline de captura está sendo executado, evitando, assim, inversões de prioridade de thread.

Requisitos de InputStream

Contagem de fluxos

• O número de fluxos de entrada no Dispositivo MFT deve ser o mesmo que o número de fluxos com suporte pelo driver.

TiposDeMídia

• 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 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 Dispositivo MFT 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 Dispositivo MFT 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 do dispositivo que especifica o CLSID do CoClass do dispositivo MFT.

[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:

[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 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 da câmera no Windows.

Antes do Windows 10, na versão 1703, o pipeline da câmera suportava apenas um plug-in de extensão DMFT.

A partir do Windows 10, versão 1703, o pipeline de câmera do Windows dá suporte a uma cadeia opcional de DMFTs com no máximo dois DMFTs.

A partir do Windows 11, versão 22H2, o pipeline de câmera do Windows dá suporte a uma cadeia opcional de DMFTs com no máximo quatro DMFTs.

Isso fornece maior flexibilidade para OEMs e IHVs fornecerem valor agregado na forma de fluxos de câmera pós-processamento. Por exemplo, um dispositivo pode usar PDMFT junto com um DMFT IHV e um DMFT OEM.

A figura a seguir ilustra a arquitetura que envolve uma cadeia de DMFTs.

Cadeia DMFT.

Os exemplos 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 poderá atuar como um intermediário, bastando encaminhar a amostra para o próximo DMFT.

Para controles como KsProperty, a chamada aumenta o fluxo – o último DMFT na cadeia recebe a chamada primeiro. A chamada pode ser tratada lá ou ser passada para o DMFT anterior na sequência.

Os erros são propagados de DMFT para DTM e, em seguida, para aplicativos. Para DMFTs IHV/OEM, a falha de qualquer DMFT ao instanciar é um erro fatal para o DTM.

Requisitos para DMFTs:

• A contagem de pinos de entrada do DMFT deve corresponder à contagem de pinos de saída do DMFT anterior. Caso contrário, a DTM falhará durante a inicialização. No entanto, o número de pinos de entrada e saída do mesmo DMFT não precisa corresponder.

• O DMFT precisa dar suporte às interfaces: IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl e IMFMediaEventGenerator. O IMFTransform pode precisar ser suportado se houver MFT0 configurado ou se o próximo DMFT na cadeia exigir suporte ao IMFTransform.

• Em sistemas de 64 bits que não fazem uso do Frame Server, tanto os DMFTs de 32 bits quanto os de 64 bits devem ser registrados. Dado que uma câmera USB pode ser conectada a um sistema arbitrário, para câmeras USB externas (ou que não estão incluídas na caixa), o fornecedor da câmera USB deve fornecer DMFTs de 32 bits e 64 bits.

Configurar a cadeia DMFT

Um dispositivo de câmera pode, opcionalmente, fornecer um objeto DMFT COM em uma DLL usando um arquivo INF personalizado que usa seções da caixa de entrada USBVideo.INF.

No arquivo INF personalizado, especifique os CLSIDs DMFT na seção "Interface AddReg", adicionando a seguinte entrada de registro:

CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%

Conforme mostrado nas configurações INF de exemplo abaixo (substitua o %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, e a primeira é mais próxima de DevProxy e a última é a última DMFT na sequência.

O DMFT CLSID da plataforma é {3D096DDE-8971-4AD5-98F9-C74F56492630}.

Alguns exemplos de configurações de CameraDeviceMftCLSIDChain :

• Sem DMFT IHV/OEM ou DMFT de plataforma

  • CameraDeviceMftCLSIDChain = "" (ou não é necessário especificar esta entrada do Registro)

• IHV/OEM DMFT

  • CameraDeviceMftCLSIDChain = CLSID %Dmft.%

• Plataforma DMFT <–> IHV/OEM DMFT

  • CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%

  • Aqui está uma captura de tela da chave do registro de resultados para uma câmera USB com a Plataforma DMFT e um DMFT (com GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) na cadeia.

• IHV/OEM DMFT0 <–> IHV/OEM DMFT1

  • CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,

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, então a cadeia terá a aparência (se a câmera for USB e for compatível com a Plataforma DMFT e a Plataforma DMFT estiver habilitada) DevProxy <–> Plataforma DMFT <–> OEM/IHV DMFT ou (se a câmera não for compatível com a Plataforma DMFT ou se a Plataforma DMFT estiver desabilitada) DevProxy <–> OEM/IHV DMFT.

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 MFT de MFTs de dispositivos

Em vez de registrar o objeto COM do driver globalmente, o objeto COM do driver é registrado na chave do dispositivo. Isso permite o registro MFT COM de dentro do contêiner e evita a criação de chaves globais no registro, preservando assim o isolamento do pacote do driver. Os MFTs também são registrados na chave do dispositivo por motivos semelhantes.

Alterações no INF do driver

Após a instalação do driver de dispositivo, o INF agora deve fazer todos os registros de objetos COM e MFT na chave do dispositivo. Os registros MFT e COM devem ser alterados conforme mostrado aqui:

Registros MFT

Os registros COM

No Windows 26100 e posterior, todo registro COM para MFTs de dispositivo deve usar as 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 do Device MFT COM usavam AddReg para instalar manualmente a classe COM.

A sintaxe INF para diferenciação com base na versão do sistema operacional pode ser encontrada na combinação de 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 tradicionais do Registro para 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 mais recentes do sistema operacional. 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 de MFT em uma nova compilação, o INF cria 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 direcionamento de 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