Captura baseada em porta de vídeo
Os dispositivos de captura baseados em portas de vídeo devem fornecer um pino de porta de vídeo que se conecte ao gerenciador de portas de vídeo. O pino da porta de vídeo permite que o transporte baseado em hardware exiba o fluxo de visualização sem sobrecarga de CPU ou barramento de interconexão de componente periférico (PCI). Um pino separado fornece capacidade de captura (por exemplo, quando o vídeo capturado deve ser gravado no disco). Durante o processo de captura, os buffers de captura são fornecidos ao driver de vídeo, que preenche o buffer por masterização de barramento. A interação entre o minidriver de captura e o driver de vídeo é descrita em mais detalhes mais adiante nesta seção e no Transporte de Vídeo em Modo Kernel.
Em sistemas que executam o Microsoft Windows 98 SE ou Windows 2000, o filtro Misturador de sobreposição (parte do filtro Gerenciador de porta de vídeo em sistemas operacionais posteriores) não oferece suporte a conexões de porta de vídeo em monitores secundários. A conexão de pino falha nesse caso. Há suporte para conexões de porta de vídeo em monitores secundários em sistemas que executam o Windows Millennium Edition (Windows Me) e o Windows XP.
Se um dispositivo oferecer suporte à captura VBI, ele normalmente expõe dois pinos adicionais: VPVBI e VBI. O filtro do gerenciador de portas de vídeo usa o pino VPVBI para alocar superfícies de porta de vídeo para captura VBI. O próprio pino VBI fornece os exemplos VBI brutos.
O diagrama a seguir mostra os caminhos separados para captura VPVBI e VBI.
Os conjuntos de propriedades específicos para esse tipo de gráfico de filtro são KSPROPSETID_VPConfig e KSPROPSETID_VPVBIConfig e PROPSETID_ALLOCATOR_CONTROL.
Usando as VPEs (Video Port Extensions, extensões de porta de vídeo)
Nota: Os parágrafos a seguir se aplicam somente aos sistemas operacionais anteriores à próxima versão do Windows Vista. O VPE está desabilitado no Windows Vista se o driver de vídeo usar o novo modelo de exibição de driver do Windows Vista (LDDM).
Os minidrivers de captura de vídeo podem usar a função DxApi para se comunicar com o driver de miniporta de vídeo para permitir que o streaming de vídeo de captura seja transportado através do barramento de porta de vídeo entre o hardware de captura e o hardware de exibição. O fluxo consiste em campos sequenciais de vídeo NTSC, PAL ou SECAM e pode incluir dados em branco (VBI) e timecode (sincronização horizontal e sincronização vertical). As características do fluxo de vídeo, incluindo dimensão, formato de cor, frequência, dimensionamento e recorte, são configuradas no modo de usuário por meio da interface VPE DirectDraw. Depois que o streaming é iniciado, o DxApi é chamado no modo kernel para capturar quadros individuais. Para suportar alterações de exibição, como alterações na resolução ou alternar para ou de prompts de comando de tela cheia, os minidrivers de captura de vídeo também devem se registrar com o driver de miniporta de vídeo para que possam responder a esses eventos de alteração de exibição.
Os VPEs e a função DxApi foram introduzidos na DDI do DirectDraw com DirectX 5.0. DxApi é suportado pelo driver de miniporta de vídeo no Windows 2000 e sistemas operacionais posteriores. Um driver de miniporta de exibição virtual (miniVDD) oferece suporte a DxApi nos sistemas operacionais Windows 98 e Windows Me. Para habilitar o transporte de vídeo no modo kernel usando DxApi, um minidriver de captura de vídeo WDM deve incluir o arquivo de cabeçalho ddkmapi.h (API de modo kernel DirectDraw) e o link com a biblioteca dxapi.lib . A biblioteca DxApi usa a funcionalidade exportada pelo dxapi.sys. DxApi.sys está disponível somente quando o DirectDraw é carregado porque DxApi faz parte dos VPEs para o DirectDraw DDI.
DxApi é uma única API de modo kernel que é exposta por DxApi.sys. A extensão de porta de vídeo é uma API de modo de usuário que é exposta por DDraw.dll. Um minidriver de captura de vídeo deve fazer várias chamadas diferentes para DxApi para configurar o hardware da porta de vídeo para transmitir corretamente.
DxApi é uma única função que encapsula vários identificadores de função. Minidrivers passam o identificador de função desejado no primeiro argumento para DxApi. Os argumentos restantes para DxApi são para os buffers alocados pelo minidriver para as estruturas que correspondem a identificadores de função e comprimentos de buffers. O comportamento das funções e o tamanho e formato dos buffers de entrada e saída dependem do identificador de função especificado. Esse comportamento está documentado em DxApi função e identificadores.
O WDK fornece dois drivers de exemplo que mostram como implementar a funcionalidade DxApi . O exemplo ATIWDM requer que hardware específico esteja presente para operar. O exemplo TestCap não requer hardware e funciona em todas as plataformas. Você pode usar a ferramenta GraphEdt para interagir com qualquer uma das amostras.
As funções comuns que um minidriver de captura de vídeo deve chamar DxApi para executar são as seguintes:
Abra um identificador para DirectDraw no modo kernel (identificador de função DxApi definido como DD_DXAPI_OPENDIRECTDRAW). Esta operação deve ser realizada em IRQL = PASSIVE_LEVEL.
Obtenha os recursos de modo kernel da porta de vídeo de hardware (identificador de função DxApi definido como DD_DXAPI_GETKERNELCAPS).
Registre retornos de chamada para manipular eventos DirectDraw, como alternâncias de modo para um prompt de comando de tela inteira (identificador de função DxApi definido como DD_DXAPI_REGISTER_CALLBACK).
Abra uma alça para direcionar superfícies do DirectDraw (identificador de função DxApi definido como DD_DXAPI_OPENSURFACE).
Cancele o registro de retornos de chamada (identificador de função DxApi definido como DD_DXAPI_UNREGISTER_CALLBACK).
Feche alças para superfícies, bem como para DirectDraw no modo kernel (identificador de função DxApi definido como DD_DXAPI_CLOSEHANDLE)
Dispositivos filho de porta de vídeo e gerenciamento de energia
Dispositivos filho de porta de vídeo, como sintonizador de TV e adaptadores de combinação de vídeo, podem bloquear transições de estado de energia quando o minidriver está em uso. O bloqueio de transição de estado de energia ocorre quando o minidriver está ativamente em uso (pinos ou filtros estão abertos). Se o minidriver estiver carregado, mas não tiver pinos ou filtros em uso, ocorrerão transições de estado de energia de S0 (totalmente alimentado) para estados de energia mais baixa (por exemplo, S1, S2, S3 e S4). O bloqueio de transição de estado de energia ocorre apenas com minidrivers de classe Stream que são clientes de dispositivos filho de porta de vídeo.
Uma isenção de WHQL está disponível para dispositivos que atendem a esses critérios, para que os fornecedores ainda possam obter um logotipo.