Guia de design para dispositivos MFT

A pilha de captura de vídeo no Windows suporta uma extensão em modo de utilizador na forma de DMFT. Este é um componente de extensão por dispositivo que os IHVs fornecem, e o pipeline de captura insere como a primeira transformação após a captura. O DMFT recebe quadros pós-processados do dispositivo. Outras operações de pós-processamento nos quadros podem ser realizadas dentro do DMFT. O DMFT pode receber frames de todos os fluxos do dispositivo e pode expor qualquer número de fluxos de saída conforme a necessidade.

Este artigo descreve o design de uma extensão de 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

Objetivos de design

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

• Suporta qualquer número de entradas provenientes do dispositivo

• Suporta qualquer número de saídas (o requisito atual é de três fluxos: visualização, gravação e foto)

• Encaminha todos os controlos do dispositivo para o MFT do dispositivo, que, opcionalmente, pode manipulá-los ou encaminhá-los para o dispositivo.

• Pós-processamento paralelo do fluxo capturado

• Permitir o processamento 3A independentemente da taxa de fotogramas

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

• Acesso aos recursos da GPU

• Acesso às filas de trabalho do MF MMCSS

• Acesso ao MF Allocator

• Interface simples (semelhante ao MFT)

• Arquitetura interna flexível para extensibilidade IHV/OEM

Restrições de design

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

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

Arquitetura de pilha de captura

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

Gerenciador de transformação de dispositivo (DTM)

A pilha de captura introduz um novo componente fornecido pelo sistema, o Gestor de Transformação de Dispositivos (DTM). Isso reside dentro do DeviceSource e gerencia o Devproxy MFT e o Device MFT. O DTM faz a negociação do Tipo de Mídia, a propagação de amostras e a gestão de todos os eventos MFT. Ele também expõe a interface IMFTransform para DeviceSource e outras interfaces privadas necessárias que DeviceSource precisa para gerenciar fluxos de dispositivos. Este componente abstrai o Devproxy e o Device MFT do fluxo de trabalho. O pipeline apenas vê o DTM como o dispositivo e os fluxos do DTM como os fluxos do dispositivo.

Devproxy

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

MFT do dispositivo

Device MFT é uma extensão de modo de usuário para o driver de captura. É um m x n MFT assíncrono. Está instalado no sistema junto 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 igual ao número de pinos Ks expostos pelo dispositivo. Os tipos de mídia suportados pelos fluxos de entrada do Device MFT devem ser os mesmos que os tipos de mídia expostos pelos pinos KS.

O número de fluxos de saída expostos pelo Device MFT são os fluxos vistos pelo DeviceSource e pela pilha de captura, API de captura e aplicativos e podem ser um, dois ou três fluxos. As contagens de fluxo de entrada e saída do Device 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 Device MFT, o segundo Ks Pin representado no modo de usuário pelo fluxo de saída do Devproxy com o segundo fluxo de entrada do Device MFT, e assim por diante.

O Device MFT recebe um ponteiro para Devproxy, dispositivo DX e MF WorkQueue ID. Os quadros que saem do dispositivo são enviados diretamente para a entrada do MFT do dispositivo correspondente como amostras MF. Com tudo isso, o Device MFT pode realizar o pós-processamento das amostras capturadas e fornecer amostras para os pinos de pré-visualização, gravação e fotografia.

Todos os comandos e controles que vão para o dispositivo são redirecionados para o Device MFT. O Device MFT lida com os controles ou os passa para o driver através do Devproxy. Isso simplifica a manipulação de comandos pela pilha de drivers de captura.

Visão geral funcional

Na inicialização do pipeline de captura, se houver um Device MFT 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 Device MFT e executa validações básicas, por exemplo, verifica se o número de pinos de saída do Devproxy é o mesmo que o número de pinos de entrada do Device MFT, suporte para interfaces obrigatórias e assim por diante.

DeviceSource consulta o DTM para obter os tipos de mídia de saída suportados. O DTM obtém isso dos pinos de saída do Device MFT. 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, 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 Device MFT usando o método SetOutputStreamState .

Quando SetOutputStreamState é chamado, o Device MFT posta 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 espera. Em resposta a essa mensagem, o DTM consulta o tipo de mídia de entrada preferencial para o fluxo de entrada do Device MFT usando GetPreferredInputStreamState. Isso define o tipo de mídia no fluxo de saída correspondente do Devproxy. Se isso for bem-sucedido, o DTM definirá esse mesmo tipo de mídia no fluxo de entrada do Device MFT usando SetInputStreamState. Depois de receber esta chamada, Device MFT conclui SetOutputStreamState.

O CaptureEngine seleciona fluxos individuais habilitando fluxos específicos no DeviceSource. Isso é propagado para Device MFT pelo DTM por meio de uma chamada SetOutputStreamState . O Device MFT coloca os fluxos de saída específicos no estado solicitado. Como mencionado acima, o Device MFT também notifica o DTM sobre os fluxos de entrada necessários que precisam ser habilitados. Isso resulta na propagação da seleção de fluxo pelo DTM para o Devproxy. No final deste processo, todos os fluxos necessários, em Devproxy e Device MFT, estão prontos para serem transmitidos.

SourceReader inicia o DeviceSource quando o CaptureEngine chama ReadSample. Por sua vez, 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 o Devproxy e o Device MFT ao propagar as mensagens MFT_MESSAGE_NOTIFY_BEGIN_STREAMING e MFT_MESSAGE_NOTIFY_START_OF_STREAM.

O DTM chama SetOutputStreamState nas saídas do Device MFT com o parâmetro streaming state. O dispositivo MFT começa a transmitir nesses fluxos de saída. O DTM inicia o streaming nos fluxos de saída Devproxy que têm um tipo de média válido definido. O Devproxy aloca as amostras e as busca no dispositivo. Essas amostras são enviadas para o MFT do dispositivo através do pino de entrada relevante. O Device MFT processa essas amostras e fornece a saída para DeviceSource. De DeviceSource, as amostras fluem através de SourceReader para CaptureEngine.

O CaptureEngine desativa fluxos individuais por meio de uma interface interna no DeviceSource. Isso é traduzido como a desabilitação de um fluxo de saída específico no Device MFT por meio de SetOutputStreamState. Por sua vez, o Device MFT pode solicitar a desativação de fluxos de entrada específicos por meio do evento METransformInputStreamStateChanged . O DTM propaga isso para fluxos Devproxy correspondentes.

Contanto que o MFT do dispositivo esteja em estado de streaming, este pode solicitar a transição de qualquer fluxo de entrada 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 pipeline de captura. Por exemplo, os fluxos de visualização, registro e fotos são habilitados ou desabilitados pelo pipeline de captura. Mesmo quando as saídas estão desativadas, um fluxo de entrada ainda pode ser transmitido, desde que o próprio Device MFT esteja em estado de streaming.

Tempo de vida útil do dispositivo MFT

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

Do ponto de vista do pipeline, quando o DeviceSource é criado, o Device MFT também é criado, e quando o DeviceSource é desligado, o Device MFT é desligado de forma síncrona.

Para suportar o desligamento, o MFT do dispositivo deve suportar a interface IMFShutdown . Depois que o Device MFT-Shutdown> for chamado, qualquer outra chamada de interface no Device MFT 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 que saia do driver da câmera é alimentado diretamente no MFT do dispositivo para processamento posterior.

Devproxy aloca os buffers com base na preferência do driver. Exigimos que o MFT do dispositivo utilize as APIs do alocador MF para alocar as amostras necessárias para os seus pinos de saída em transformações fora de lugar.

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

Os clientes do SourceReader são capazes de ver os tipos de mídia expostos pelos fluxos de saída do Device MFT como tipos de mídia suportados nativamente. Quando o tipo de mídia nativo é alterado, SourceReader envia chamadas de notificação de tipo de mídia para o MFT do dispositivo por meio do DeviceSource. É responsabilidade do Device MFT esvaziar todas as amostras pendentes da fila desse fluxo e alternar para o novo tipo de mídia nesse fluxo de forma oportuna. Se houver necessidade de alterar o tipo de mídia de entrada, então ele deve alterar o tipo de mídia de entrada atual para aquele. O DTM obtém o tipo de mídia atual do fluxo de entrada do Device MFT e o define nos fluxos de saída do Devproxy e na entrada do Device MFT após cada alteração de tipo de mídia nativa.

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

Uma vez que este é um m x n MFT, pode haver repercussões nos tipos de mídia do pino de streaming de entrada e mudança de estado quando os tipos de mídia ou o estado do pino de streaming de saída mudam. Especificamente quando ocorrem as seguintes alterações:

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

  • Quando uma aplicação altera o tipo de mídia nativo, essa alteração percorre a pilha de captura chegando ao Device MFT como uma modificação no tipo de mídia do pino de saída.

  • Quando o tipo de mídia de saída muda, ele pode disparar uma alteração de tipo de mídia de entrada. Por exemplo, suponha que todos os pinos de saída estejam transmitindo em 720p. Isso resulta em streaming 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 MFT do dispositivo que estava buscando dados para o fluxo de registro teria que alterar seu tipo de mídia.

• O pino de saída está desativado

  • Quando um aplicativo desativa uma das saídas do Device MFT quando a mesma entrada é compartilhada por mais de uma saída, para otimização, a entrada pode ter que alterar o tipo de mídia. 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 deve mudar seu tipo de mídia para 720p para economizar energia e melhorar o desempenho.

O DTM lida com notificações METransformInputStreamStateChanged da Device MFT para alterar o tipo de média e o estado na entrada da Device MFT e na saída Devproxy sob estas condições.

Tipos de mídia de saída preferidos de MFT de dispositivo

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

Dispositivo de descarga MFT

São necessários dois tipos de limpeza durante a gestão do Device MFT:

• Limpeza global

  • Descarga ampla do MFT no dispositivo. Isso normalmente acontece quando o DTM está prestes a enviar uma mensagem de interrupção de streaming para o Device MFT.

  • Espera-se que o MFT do dispositivo elimine todas as amostras de suas filas de entrada e saída e retorne de forma síncrona.

  • O MFT do dispositivo não deve pedir novas entradas ou enviar notificações sobre novas saídas disponíveis.

• Descarga local

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

Todos os eventos que foram postados antes da liberação são descartados pelo Gerenciador de MFT de Dispositivo. Após a operação de "flush", o dispositivo MFT redefine sua contagem interna de rastreamento de METransformHaveOutput.

Drenagem do dispositivo MFT

O MFT do dispositivo não receberá uma mensagem de drenagem separada, pois não há necessidade de drenagem em uma fonte de captura ao vivo.

Disparador fotográfico

Neste modelo, em vez de enviar o gatilho de captura de fotos e os gatilhos de início e fim de sequência de captura de fotos diretamente para o controlador, eles são redirecionados para o dispositivo MFT. A MFT do dispositivo manipula o gatilho ou encaminha-o para o driver da câmera, conforme necessário.

Início quente

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

Sequência de fotos variável

Com esta arquitetura, a sequência de fotos é implementada com o driver de dispositivo da câmera e o Device MFT, reduzindo significativamente a complexidade do driver de dispositivo da câmera. Os gatilhos de início e parada da sequência de fotos são enviados para o Device MFT e ajudam a lidar mais facilmente com a sequência de fotos.

Foto de confirmação

O MFT do dispositivo suporta a confirmação de fotos através da interface IMFCapturePhotoConfirmation . O pipeline recupera essa interface por meio do método IMFGetService::GetService .

Metadados

Devproxy consulta o driver para o tamanho do buffer de metadados e aloca a memória para metadados. Os metadados provenientes do driver são definidos pelo Devproxy na amostra. A MFT do dispositivo absorve os metadados da amostra. Os metadados podem ser transmitidos com a amostra através do seu fluxo de saída ou utilizados para o seu pós-processamento.

Com o Device MFT suportando qualquer número de entradas, um pino de entrada dedicado pode ser usado apenas para metadados ou metadados fora de banda. O tipo de mídia para este pino é 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 em estado de streaming quando o Device MFT inicia o streaming. Por exemplo, quando os fluxos de saída são selecionados para streaming, o Device 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 .

Nota: Não é necessário que o número de pinos de entrada corresponda ao número de pinos de saída neste modelo. Pode haver um pino separado dedicado para metadados ou 3A.

Tratamento de eventos do Gerenciador de Transformação de Dispositivo (DTM)

Os eventos do Device Transform Manager são definidos nos seguintes artigos de referência:

• METransformFlushInputStream

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformNeedInput

Interface IMFDeviceTransform

A interface IMFDeviceTransform é definida para interagir com o Device MFT. Esta interface facilita a gestão de m entradas e n saídas do dispositivo MFT. Juntamente com outras interfaces, o Device 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 Device MFT e para o DeviceSource.

Requisitos de MFT para dispositivos

Requisitos da interface

As MFTs de dispositivo devem suportar as seguintes interfaces:

• IMFDeviceTransform

• IKsControl

  • Isso permite que todos os ksproperties, eventos e métodos passem pelo Device MFT. Isso dá ao Device MFT a capacidade de lidar com essas chamadas de funções dentro do Device MFT ou apenas encaminhá-las para o driver. No caso em que os métodos KsEvent são manipulados, o MFT do dispositivo tem que realizar os seguintes passos:

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

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

    • Se o Device MFT manipular eventos que não são do tipo KSEVENT_TYPE_ONESHOT, ele deverá duplicar o identificador quando receber KSEVENT_TYPE_ENABLE e chamar CloseHandle no identificador duplicado quando o evento ks for desativado através de chamar 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 do evento e a sua duração são válidos. Os dados do evento identificam unicamente um evento ks específico.

    • Se o Device MFT manipular eventos que não sejam do tipo KSEVENT_TYPE_ONESHOT, ele deverá duplicar o identificador quando receber KSEVENT_TYPE_ENABLE e deverá chamar CloseHandle nos identificadores duplicados quando os eventos KS forem desativados chamando a função KsEvent com todos os parâmetros configurados para zero.

• IMFRealTimeClientEx

• IMFMediaEventGenerator

• FMIShutdown

• IMFSampleAllocatorControl

Requisitos de notificação

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

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

Requisitos de thread

O dispositivo MFT não deve criar os 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 é para garantir que todos os threads em execução no Device MFT obtenham a prioridade correta na qual o pipeline de captura está sendo executado e evitar inversões de prioridade de thread.

Requisitos do InputStream

Contagem de fluxos

• O número de fluxos de entrada no Device MFT deve ser o mesmo que o número de fluxos suportados pelo driver.

MediaTipos

• O número de tipos de mídia e os tipos de mídia reais suportados pela entrada do MFT do dispositivo devem corresponder ao número e aos tipos de tipos de mídia suportados pelo driver.

• O número pode ser diferente apenas se os tipos de mídia suportados pela entrada do MFT do dispositivo forem um subconjunto dos tipos de mídia suportados pelo driver.

• Os tipos de mídia suportados pelo driver e entrada do Device MFT podem ser tipos de mídia padrão ou personalizados.

Como registar o MFT do dispositivo

O dispositivo de câmera INF deve ter a seguinte entrada de interface de dispositivo que especifica o CLSID da 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:

[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 de dispositivos

Device MFT é 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, 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âmara do Windows suporta uma cadeia opcional de DMFTs, com um máximo de dois DMFTs.

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

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

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

Captura de amostras fluindo do driver da câmara para o DevProxy e, em seguida, através das cadeias DMFT. Cada CPO-D na cadeia pode processar a amostra. Se o DMFT não quiser processar a amostra, pode agir como um intermediário e simplesmente passar a amostra para o próximo DMFT.

Para controles como KsProperty, a chamada é direcionada para cima na linha – o último DMFT na cadeia recebe a chamada primeiro. A chamada pode ser tratada lá 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, se algum dos DMFT falhar ao instanciar, isso é um erro fatal para DTM.

Requisitos relativos aos CPOD:

• A contagem de pinos de entrada do CPOD deve corresponder à contagem de pinos de saída do CPOD anterior. Caso contrário, o DTM falharia durante a inicialização. No entanto, as contagens de pinos de entrada e saída do mesmo DMFT não precisam ser iguais.

• DMFT precisa suportar as interfaces - IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl e IMFMediaEventGenerator; o suporte ao IMFTransform pode ser necessário se houver um 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. Dado que uma câmara USB pode ser ligada a um sistema arbitrário, para câmaras USB "externas" (ou não internas), o fornecedor da câmara USB deve disponibilizar 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 ficheiro .INF personalizado, a seção "Interface AddReg", especifique os CLSIDs DMFT adicionando a seguinte entrada do registo:

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

Como mostrado nas configurações INF de exemplo abaixo (substitua o% 0.CLSID %Dmfte %% 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 o primeiro está mais próximo do DevProxy e o último é o último DMFT na cadeia.

Plataforma DMFT CLSID é {3D096DDE-8971-4AD5-98F9-C74F56492630}.

Alguns exemplos de configurações CameraDeviceMftCLSIDChain :

• Sem IHV/OEM DMFT ou plataforma DMFT

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

• IHV/OEM DMFT

  • CameraDeviceMftCLSIDChain = %Dmft.CLSID%

• Plataforma DMFT <-> IHV/OEM DMFT

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

  • Aqui está uma captura de tela da chave de registro de resultado para uma câmera USB com 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 o CameraDeviceMftCLSIDChain não estiver configurado e o legado CameraDeviceMftCLSID estiver configurado, então a cadeia seria assim: (se for uma câmera USB e for suportada pela Platform DMFT, e a Platform DMFT estiver ativada) DevProxy <–> Platform DMFT <–> OEM/IHV DMFT ou (se a câmera não for suportada pela Platform DMFT ou a Platform DMFT estiver desativada) 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%

Com objeto e registro MFT de MFTs de dispositivo

Em vez de registar o objeto COM do driver globalmente, o objeto COM do driver é registado associado à chave do dispositivo. Isso permite o registro MFT COM de dentro do contêiner e impede que chaves de registro globais sejam criadas, preservando assim o isolamento do pacote de driver. MFTs são registados também sob a chave do dispositivo por razões semelhantes.

Alterações ao driver INF

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

Registos MFT

Registos COM

No Windows 26100 e versões posteriores, todos os registos COM para MFTs de dispositivos devem 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 Device MFT COM Registration usavam AddReg para instalar manualmente a classe COM.

A sintaxe INF para diferenciar com base na versão do sistema operacional pode ser encontrada em Combinando 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 SO utilizam as chaves de registo tradicionais para fins de compatibilidade. O INF deve configurar essas chaves do Registro no local antigo em compilações mais antigas do sistema operacional e criar as novas chaves em seu novo local para compilações mais recentes do sistema operacional. Por exemplo, para um registro MFT em uma compilação mais antiga, o INF cria a chave na seguinte entrada do Registro:

HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\ 

Para um registro MFT em uma nova compilação, o INF cria a chave na seguinte entrada do Registro:

**software key**\MediaFoundation\Transforms\{clsid}\ 

Esta 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 para direcionamento de diferentes versões de sistemas operativos é apresentado 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