Horloges maîtres

Les minidrivers peuvent synchroniser des flux avec des horloges créées par d’autres minidrivers ; plusieurs flux peuvent être synchronisés avec une horloge. Si la broche utilise ou produit une telle horloge principale, le minidriver doit prendre en charge KSPROPERTY_STREAM_MASTERCLOCK. Les clients peuvent également utiliser cette propriété pour définir l’horloge principale pour la broche. Les broches qui effectuent des opérations de rendu et de capture utilisent fréquemment une horloge principale. Le minidriver est chargé de libérer les références d’horloge lors de sa terminaison.

L’interface d’une horloge principale est un objet de fichier qui prend en charge les méthodes, les propriétés et les événements.

Toutes les requêtes sur l’objet fichier ne sont disponibles qu’à PASSIVE_LEVEL. Toutefois, la requête de position de l’horloge est également prise en charge par le biais d’un pointeur d’appel de fonction direct disponible à DISPATCH_LEVEL, qui est valide tant que l’objet de fichier est valide. Cet appel direct doit être passé à l’objet de fichier de l’horloge en tant que paramètre de contexte.

Le handle de fichier est acquis via une demande de création sur une instance de pin de filtre, tout comme la création de broche est effectuée par IRP_MJ_CREATE. La requête entraîne la création d'un descripteur de fichier, tout comme un descripteur de fichier pour une broche, avec ses propres informations de contexte. Ce handle de fichier est ensuite repassé à l’appelant et peut être utilisé pour définir l’horloge principale pour les filtres en mode noyau. Au moment où le filtre est affecté à l’horloge principale du graphe, une instance de broche peut interroger l’objet de fichier parent pour déterminer s’il détient l’horloge principale.

Lorsqu'un filtre reçoit le descripteur de fichier de cette horloge de référence, il peut l'utiliser ensuite pour interroger les propriétés. Si une horloge principale est basée sur un filtre en mode noyau, elle doit prendre en charge une interface pour interroger le handle de fichier dans la partie en mode noyau de l’horloge principale. Si l’interface n’est pas prise en charge, il est supposé que l’horloge est basée sur le mode utilisateur et que les filtres en mode noyau ne peuvent pas la synchroniser.

Le filtre proxy DirectShow, après avoir demandé le descripteur de l'horloge principale, le transmet ensuite à son descripteur de fichier de filtre en mode noyau sous-jacent. Le filtre en mode noyau fait référence à l’objet de fichier sous-jacent. Si le filtre avait déjà une horloge principale, il déréférence l’objet de fichier et utilise le nouveau handle. Pour ce faire, le filtre doit être dans l’état Stop.

L’heure physique sur l’objet horloge principale est fréquemment basée sur le matériel. Si un filtre qui présente l’horloge principale n’a pas d’horloge physique, l’heure de flux progresse en fonction des horodatages des données présentées. Dans ce cas, les horodatages peuvent s’arrêter en raison d’un manque de données.

L’heure physique derrière l’horloge principale peut être distante, auquel cas il incombe au proxy local de fournir des lectures précises. Par exemple, le proxy a la responsabilité de compenser le délai sur une connexion 1394 ou d’effectuer une moyenne du délai sur un réseau. En outre, si un autre filtre de noyau est un proxy pour un deuxième appareil sur le même bus 1394, les deux appareils peuvent négocier une méthode privée d’interfaçage avec l’horloge principale. Dans ce cas, les appareils doivent utiliser des interfaces privées pour déterminer le type d’horloge afin de vérifier la compatibilité.