Horloges principales

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

L’interface d’une horloge master 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 d’horloge est également prise en charge par le biais d’un pointeur d’appel de fonction directe disponible sur DISPATCH_LEVEL, qui est valide tant que l’objet fichier est valide. Cet appel direct doit être passé à l’objet fichier de l’horloge en tant que paramètre de contexte.

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

Lorsqu’un filtre reçoit le handle de fichier pour cette horloge master, il peut ensuite être utilisé pour interroger les propriétés. Si une horloge master est basée sur un filtre en mode noyau, elle doit prendre en charge une interface permettant d’interroger le handle de fichier sur la partie en mode noyau de l’horloge master. 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 se synchroniser avec elle.

Le filtre proxy DirectShow demandant le handle d’horloge master le transmet ensuite à son handle 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 master, il déréférence l’objet de fichier et utilise le nouveau handle. Pour ce faire, le filtre doit être à l’état Arrêter.

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

Le temps physique derrière l’horloge master peut être distant, auquel cas il incombe au proxy local de fournir des lectures précises. Par exemple, le proxy est responsable de la compensation du retard sur une connexion 1394 ou de la 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 master. Dans ce cas, les appareils doivent utiliser des interfaces privées pour déterminer le type d’horloge afin de vérifier la compatibilité.