Relógios Mestres

Os minidrivers podem sincronizar fluxos com relógios criados por outros minidrivers; vários fluxos podem ser sincronizados com um relógio. Se o pino usar ou produzir esse relógio mestre, o minidriver deverá dar suporte a KSPROPERTY_STREAM_MASTERCLOCK. Os clientes também podem usar essa propriedade para definir o relógio mestre para o pino. Os pinos que executam operações de renderização e captura frequentemente usam um relógio mestre. O minidriver é responsável por liberar referências de relógio após a terminação.

A interface para um relógio mestre é um objeto de arquivo que dá suporte a métodos, propriedades e eventos.

Todas as consultas no objeto de arquivo só estão disponíveis em PASSIVE_LEVEL. No entanto, a consulta da posição do relógio também é suportada por meio de um ponteiro de chamada de função direta disponível em DISPATCH_LEVEL, que permanece válido enquanto o objeto de arquivo estiver válido. Essa chamada direta deve ser passada para o objeto de arquivo do relógio como um parâmetro de contexto.

O identificador de arquivo é adquirido por meio de uma solicitação de criação em uma instância de pino de filtro, assim como a criação do pino é realizada pelo IRP_MJ_CREATE. A solicitação faz com que um identificador de arquivo seja criado, assim como um identificador de arquivo para um pin é criado, com suas próprias informações de contexto. Esse identificador de arquivo é passado de volta para o chamador e pode ser usado para definir o relógio mestre para filtros de modo kernel. No momento em que o filtro recebe o relógio mestre do grafo, uma instância de pino pode consultar o objeto de arquivo pai para verificar se ele detém o relógio mestre.

Quando um filtro recebe o identificador de arquivo para esse relógio mestre, ele pode ser usado para consultar propriedades. Se um relógio mestre for baseado em um filtro de modo kernel, ele deverá dar suporte a uma interface para consultar o identificador de arquivo para a parte do modo kernel do relógio mestre. Se não houver suporte para a interface, supõe-se que o relógio seja baseado em modo de usuário e os filtros de modo kernel não poderão ser sincronizados com ela.

O filtro de proxy directShow solicitando o identificador do relógio mestre e, em seguida, passa-o para o identificador de arquivo de filtro do modo kernel subjacente. O filtro de modo kernel faz referência ao objeto de arquivo subjacente. Se o filtro já tiver um relógio mestre, ele desreferenciará o objeto de arquivo e usará o novo identificador. Para fazer isso, o filtro deve estar no estado Parar.

O tempo físico no objeto de relógio mestre é frequentemente baseado em hardware. Se um filtro que apresenta o relógio mestre não tiver relógio físico, a hora do fluxo progride de acordo com os marcadores de tempo dos dados que são apresentados. Nessa situação, os carimbos de data/hora podem parar devido à falta de dados.

O tempo físico atrás do relógio mestre pode ser remoto, nesse caso, é responsabilidade do proxy local fornecer leituras precisas. Por exemplo, o proxy tem a responsabilidade de compensar o atraso em uma conexão 1394 ou média do atraso em uma rede. Além disso, se algum outro filtro de kernel for um proxy para um segundo dispositivo no mesmo barramento 1394, os dois dispositivos poderão negociar um método privado de interface com o relógio mestre. Nesse caso, os dispositivos devem usar interfaces privadas para determinar o tipo de relógio para verificar a compatibilidade.