Guia de design do MFT do dispositivo
A pilha de captura de vídeo no Windows oferece suporte a 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 é inserido como a primeira transformação, pós-captura. O DMFT recebe quadros pós-processados do dispositivo. Outras operações de pós-processamento nos quadros podem ser feitas dentro do CPO-D. 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 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
| Termo | Descrição |
|---|---|
| KS | Driver de streaming do kernel |
| AVStream | Modelo de driver de streaming de áudio e vídeo |
| Filter | Objeto que representa uma instância de dispositivo |
| Dispositivo MFT | Extensão do driver de captura de modo de usuário fornecida por IHVs |
| Devproxy | <MF -> Marshaler AVStream |
| DTM | Gerenciador de transformação de dispositivo que gerencia devproxy e MFT de dispositivo. Representa o dispositivo no pipeline MF. |
Metas 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)
Roteia todos os controles de dispositivo para o MFT do dispositivo (que opcionalmente manipula ou passa para o dispositivo)
Pós-processamento paralelo do fluxo capturado
Permitir processamento 3A independente da taxa de quadros
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 de modo de usuário de filtro para o driver de captura. Esse componente tem acesso a APIs de MF, pools de threads, GPU e recursos de ISP. A extensão ampla do filtro fornece a flexibilidade de ter qualquer número de fluxos entre ele e o filtro Ks do dispositivo. Essa flexibilidade permite uma comunicação fora de banda perfeita 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 Gerenciador de Transformação de Dispositivo (DTM). Isso reside dentro do DeviceSource e gerencia o Devproxy MFT e o Device MFT. O DTM faz a negociação MediaType, a propagação de amostra e todo o tratamento 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. Este componente abstrai Devproxy e Device MFT do pipeline. O pipeline apenas vê o DTM como o dispositivo e os fluxos para fora do DTM como o dispositivo flui.
Devproxy
Devproxy é um MFT assíncrono que marshals os comandos e quadros de vídeo entre o driver da câmera AVStream e Media Foundation. Isso é fornecido pelo Windows e suporta n número de saídas do driver da câmera. Além disso, ele possui os alocadores para todos os pinos expostos pelo dispositivo.
Dispositivo MFT
O MFT do dispositivo é uma extensão de modo de usuário para o driver de captura. É um MFT m x n assíncrono. 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 MFT do dispositivo 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 iguais aos 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, pela API de captura e pelos 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 Ks Pin 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 MFT do dispositivo recebe um ponteiro para Devproxy, dispositivo DX e ID do 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 Device MFT pode postar processar as amostras capturadas e servir amostras para a visualização, gravação e pinos de fotos.
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 transmite ao driver por meio do Devproxy. Isso simplifica o manuseio de comandos pela pilha de drivers de captura.
Visão geral funcional
Na inicialização do pipeline de captura, se houver um MFT de dispositivo para o dispositivo, DeviceSource instanciará o DTM. Ele passa uma instância de Devproxy que representa o dispositivo para a rotina de inicialização do DTM. DTM cocria Device MFT e executa validações básicas, por exemplo, verifica se o número de pinos de saída do Devproxy é igual ao 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 com suporte. 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 ao 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 mediatype 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 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 isso 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 Device MFT conclui SetOutputStreamState.
O CaptureEngine seleciona fluxos individuais habilitando fluxos específicos no DeviceSource. Isso é propagado para o Device MFT pelo DTM por meio de uma chamada SetOutputStreamState . O MFT do dispositivo 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 no DTM propagando a seleção de fluxo para Devproxy. No final desse processo, todos os fluxos necessários, em Devproxy e Device MFT, estão prontos para transmitir.
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 o Devproxy e o Device MFT propagando mensagens MFT_MESSAGE_NOTIFY_BEGIN_STREAMING e MFT_MESSAGE_NOTIFY_START_OF_STREAM.
Observação
Aloque os recursos necessários ao iniciar o streaming em vez de inicializar o MFT do dispositivo.
O DTM chama SetOutputStreamState nas saídas do Device MFT com o parâmetro de estado de streaming. O MFT do dispositivo inicia o streaming nesses fluxos de saída. O DTM inicia o streaming nos fluxos de saída Devproxy que tem um conjunto de tipos de mídia válido. O Devproxy aloca as amostras e as busca no dispositivo. Essas amostras são alimentadas no MFT do dispositivo no pino de entrada relevante. O MFT do dispositivo processa essas amostras e fornece a saída para DeviceSource. De DeviceSource, os exemplos fluem através de SourceReader para CaptureEngine.
O CaptureEngine interrompe fluxos individuais desabilitando fluxos individuais por meio de uma interface interna no DeviceSource. Isso é traduzido em fluxo de saída específico desabilitando 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 em si 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 poderia 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 desabilitadas, um fluxo de entrada ainda pode estar transmitindo, desde que o próprio MFT do dispositivo esteja no estado de streaming.
Vida útil do dispositivo MFT
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 de 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 oferecer suporte ao desligamento, o MFT do dispositivo deve oferecer suporte à interface IMFShutdown . Depois que o 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 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 faça uso das APIs do alocador MF para alocar as amostras necessárias para seus pinos de saída para transformações não in-loco.
Alteração do 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 MFT do dispositivo como tipos de mídia suportados nativamente. Quando o mediatype nativo é alterado, SourceReader envia chamadas de notificação de mediatype 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, ele deverá alterar o tipo de mídia de entrada atual para aquele. O DTM obtém o mediatype 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 mediatype nativo.
Alteração do tipo de mídia de entrada no MFT do dispositivo
Como se trata de um MFT m x n , pode haver repercussões nos tipos de mídia do pino de streaming de entrada e na 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 um aplicativo altera o tipo de mídia nativo, ele passa pela pilha de captura em MFT do dispositivo como uma alteração de tipo de mídia de 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 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 desabilita 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 em 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 Device MFT para alterar o tipo de mídia e o estado na entrada do Device MFT e na saída 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 próxima melhor alternativa. Os tipos de mídia MJPEG e RGB não são recomendados.
MFT de dispositivo de descarga
Dois tipos de descarga são necessários durante o gerenciamento do MFT do dispositivo:
Flush global
Dispositivo de descarga em toda a MFT. Isso geralmente acontece quando o DTM está prestes a enviar uma mensagem de interrupção de streaming 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 novas entradas ou enviar notificações sobre novas saídas disponíveis.
Descarga local
- Descarga específica do pino de saída. Isso geralmente acontece quando um fluxo é interrompido.
Todos os eventos que foram postados antes da liberação são descartados pelo Gerenciador MFT do dispositivo. Após a liberação, o MFT do dispositivo redefine sua contagem de rastreamento interna METransformHaveOutput .
Dreno 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.
Gatilho fotográfico
Neste modelo, em vez de enviar o gatilho de fotos e os gatilhos de início e parada da sequência de fotos diretamente para o motorista, eles são redirecionados para o MFT do dispositivo. O MFT do dispositivo manipula o gatilho ou o encaminha para o driver da câmera, conforme necessário.
Início morno
DeviceSource tenta aquecer iniciar 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 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 é alcançado pelo MFT do dispositivo solicitando METransformInputStreamStateChanged para DTM e manipulando o método IMFDeviceTransform::SetInputStreamState .
Sequência de fotos variável
Com essa arquitetura, a sequência de fotos é implementada com o driver de dispositivo da câmera e o MFT do dispositivo, reduzindo consideravelmente a complexidade do driver do dispositivo da 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 da foto
O dispositivo MFT suporta a confirmação de fotos através da 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 no exemplo. O MFT do dispositivo consome os metadados da amostra. Os metadados podem ser transmitidos com a amostra através de seu fluxo de saída ou usados para 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 esse 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 no estado de streaming quando o MFT do dispositivo inicia o streaming. Por exemplo, quando 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 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 pino separado dedicado para metadados ou 3A.
Manipulação de eventos do Gerenciador de Transformação de Dispositivo (DTM)
Os eventos do Gerenciador de Transformação de Dispositivo 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ída do dispositivo MFT. Juntamente com outras interfaces, o Device MFT deve implementar essa interface.
Propagação de eventos gerais
Quando um evento ocorre no Devproxy (ou dentro do dispositivo), precisamos propagá-lo para o MFT do dispositivo e para o DeviceSource.
Requisitos de MFT do dispositivo
Requisitos de interface
Os MFTs de dispositivo devem oferecer suporte às seguintes interfaces:
-
Isso permite que todas as ksproperties, eventos e métodos passem pelo MFT do dispositivo. 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 ele manipula os métodos KsEvent, o MFT do dispositivo tem que fazer as seguintes etapas:
Se o Device MFT manipular qualquer evento KSEVENT_TYPE_ONESHOT , ele duplicará o identificador quando receber KSEVENT_TYPE_ENABLE.
Quando terminar de definir ou aumentar o evento, ele chama CloseHandle no identificador duplicado.
Se o MFT do dispositivo manipula eventos não KSEVENT_TYPE_ONESHOT, ele deve 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 (comprimento do evento) definidos como zero. Os dados e o comprimento do evento são válidos. Os dados do evento identificam exclusivamente um evento ks específico.
Se o MFT do dispositivo manipula eventos não KSEVENT_TYPE_ONESHOT, ele deve duplicar o identificador quando recebe KSEVENT_TYPE_ENABLE e deve chamar CloseHandle nos identificadores duplicados quando os eventos ks são desabilitados chamando a função KsEvent com todos os parâmetros definidos como zero.
Requisitos de notificação
Os 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.
Requisitos de thread
O MFT do dispositivo não deve criar seus próprios threads. Em vez disso, ele deve usar as 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 MFT do dispositivo 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 MFT do dispositivo deve ser o mesmo que o número de fluxos suportados pelo driver.
Tipos de Mídia
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 somente se os tipos de mídia suportados pela entrada de MFT de dispositivo é um subconjunto dos tipos de mídia suportados pelo driver.
Os tipos de mídia suportados pelo driver e entrada do MFT do dispositivo podem ser tipos de mídia padrão ou personalizados.
Como registrar o dispositivo MFT
O INF do dispositivo da câmera deve ter a seguinte entrada de interface do 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 nas seguintes chaves do Registro sendo inseridas:
Observação
Este é apenas um exemplo (não o 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 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, 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 oferece suporte a uma cadeia opcional de DMFTs com no máximo duas DMFTs.
A partir do Windows 11, versão 22H2, o pipeline de câmera do Windows oferece 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 de pós-processamento. Por exemplo, um dispositivo poderia usar PDMFT junto com um IHV DMFT e um OEM DMFT.
A figura a seguir ilustra a arquitetura envolvendo uma cadeia de DMFTs.
Capture amostras de fluxo do driver da câmera para o DevProxy e, em seguida, passe 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 agir como uma passagem apenas passar a amostra para o próximo DMFT.
Para controles como KsProperty, a chamada sobe – o último DMFT na cadeia recebe a chamada primeiro. A chamada pode ser tratada lá ou ser passada para 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 uma das falhas de DMFT ao instanciar é um erro fatal para DTM.
Requisitos aplicáveis às CPOD:
A contagem de pinos de entrada do DMFT deve corresponder à contagem de pinos de saída do DMFT 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 corresponder.
DMFT precisa suportar 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 a IMFTransform.
Em sistemas de 64 bits que não usam o Frame Server, os DMFTs de 32 bits e 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 não inbox), 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 costume . A seção "Interface AddReg" do arquivo INF, especifique os CLSIDs DMFT adicionando a seguinte entrada do Registro:
CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%
Conforme mostrado nas configurações de INF de exemplo 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, e o primeiro é o 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 de CameraDeviceMftCLSIDChain :
Sem IHV/OEM DMFT ou DMFT de plataforma
- CameraDeviceMftCLSIDChain = "" (ou não há necessidade de especificar essa entrada do Registro)
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 Platform DMFT e uma DMFT (com GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) na cadeia.
IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Observação
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 (se sua câmera USB e suportada pela Plataforma DMFT e Plataforma DMFT estiver habilitada) DevProxy <–> Plataforma DMFT <–> OEM/IHV DMFT ou (se a câmera não for suportada pela Plataforma DMFT ou Platform 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%
Com objeto e registro MFT de MFTs de dispositivos
Em vez de registrar o objeto COM do driver globalmente, o objeto COM do driver é registrado sob a chave do dispositivo. Isso permite o registro MFT COM de dentro do contêiner e impede que chaves globais do Registro sejam criadas, preservando assim o isolamento do pacote de driver. Os MFTs também são registrados sob a chave do dispositivo por motivos semelhantes.
Alterações no 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 de dispositivo. Os registros MFT e COM devem ser alterados conforme mostrado aqui:
Inscrições MFT
| Antes | Após |
|---|---|
| INF AddReg: HKCR, MediaFoundation\Transformações\{clsid}\... |
Software de dispositivo por instância INF AddReg: HKR, MediaFoundation\Transformações\{clsid}\... |
| Local do Registro: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Locais de registro: chave de software\MediaFoundation\Transforms\{clsid}\... |
Inscrições COM
No Windows 26100 e posterior, todo o registro COM para MFTs de dispositivo deve 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 COM do dispositivo MFT usavam o 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 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 sistema operacional usam as chaves do Registro tradicionais para 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 sob a 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 Abrindo a chave de software de um dispositivo.
Um exemplo de sintaxe de direcionamento para 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
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de