Implémentation de terminaux enfichables
Les exigences générales pour l’implémentation de terminal enfichable sont les suivantes :
- Le code de streaming sous-jacent d’un terminal enfichable doit correspondre aux fonctionnalités des msps souhaités.
- Le terminal doit utiliser des filtres DirectShow pour fonctionner avec la plupart des msps (c’est supposé à partir d’ici).
- Les terminaux audio doivent prendre en charge le PCM linéaire mono 16 bits 8 kHz pour la plupart des MPM.
- Le terminal doit activer le marshaling thread libre en implémentant IMarshal. Pour ce faire, le terminal peut appeler l’API COM CoCreateFreeThreadedMarshaler et agréger IMarshal au pointeur retourné. Le destructeur de l’objet terminal doit appeler IMarshal-Release>.
- Le terminal doit implémenter ou agréger toutes les interfaces supplémentaires spécifiques au terminal appropriées.
- L’implémentation du terminal doit être thread-safe.
- L’implémentation du terminal doit #include Termmgr.h pour la définition d’ITTerminalControl. Cela s’ajoute aux incluts et libs habituels qui sont nécessaires pour les applications TAPI 3 ou TAPI 3 sous Windows 2000 SP1.
Notes d’implémentation de l’interface et de la méthode :
Le terminal doit implémenter ITTerminal (double interface–vtable + IDispatch).
Le terminal doit retourner une représentation BSTR d’un GUID que vous avez choisi qui identifie votre type de terminal. Allouez le BSTR via SysAllocString. Pour convertir un GUID en BSTR, appelez StringFromCLSID, SysAllocString et CoTaskMemFree.
Le terminal doit généralement retourner TT_DYNAMIC si une application implémente le terminal. Le retour TT_STATIC fonctionne également, et le retour de cette valeur peut être approprié si le terminal correspond à un appareil matériel ; Toutefois, cela peut prêter à confusion pour les utilisateurs, car un terminal statique ne sera pas présent dans l’énumération de terminal statique du MSP.
Si l’implémentation du terminal ne limite pas arbitrairement le nombre de flux auxquels le terminal peut être connecté simultanément, le terminal doit toujours retourner TS_NOTINUSE.
Sinon, l’implémentation du terminal limite arbitrairement le nombre de flux auxquels le terminal peut être connecté à la fois. Dans ce cas, le terminal doit conserver le nombre de flux auxquels il est connecté. Le terminal doit incrémenter ce nombre interne sur un appel ITTerminalControl::ConnectTerminal réussi et le décrémenter sur un appel ITTerminalControl::D isconnectTerminal réussi. Dans ITTerminal::get_State, il doit retourner TS_INUSE si ce nombre est égal au nombre maximal de flux sur lequel le terminal peut être sélectionné à la fois ; sinon, il doit retourner TS_NOTINUSE. Notez que si la limite est une, le nombre peut simplement être une valeur booléenne ou une valeur TERMINAL_STATE.
Le terminal doit retourner le nom BSTR de son choix, alloué via SysAllocString. Ce nom doit être significatif pour l’utilisateur et doit être localisé.
Le terminal doit retourner son type de média, TAPIMEDIATYPE_AUDIO ou TAPIMEDIATYPE_VIDEO.
Le terminal retourne la valeur d’énumération TERMINAL_DIRECTION indiquant la direction du terminal. Si le terminal est bidirectionnel (par exemple, un pont), il doit retourner TD_BIDIRECTIONAL.
Le terminal doit implémenter ITTerminalControl (vtable uniquement).
ITTerminalControl::get_AddressHandle
Un terminal fourni par l’application doit toujours retourner null comme handle d’adresse. Cela indique au MSP que ce terminal n’a pas été créé sur un objet d’adresse MSP spécifique.
ITTerminalControl::ConnectTerminal
Lors de cet appel, le terminal ajoute son ou ses filtres au graphique donné et les connecte les uns aux autres, le cas échéant. Ensuite, le terminal doit retourner la ou les broches exposées par le terminal pour la direction de flux spécifiée.
Un terminal qui ne prend pas en charge la connexion simultanée à plusieurs flux définirait une variable interne pour TS_INUSE en cas de réussite de cette méthode.
Le terminal peut utiliser le paramètre dwTerminalDirection de cet appel pour déterminer la direction du flux auquel il est connecté. Cela est requis pour les terminaux bidirectionnels.
Notes
En règle générale (dans les classes de base MSP et dans toutes les msps connues), le code de flux MSP échoue la connexion si le terminal retourne plusieurs broches à partir d’un seul appel ConnectTerminal . Cela est très bien, car un terminal qui retourne plusieurs broches pendant la connexion nécessite que le MSP ait une connaissance spéciale du terminal pour utiliser efficacement les broches supplémentaires.
ITTerminalControl::CompleteConnectTerminal
Le terminal doit simplement retourner S_OK. Le terminal peut également effectuer une initialisation post-connexion s’il le faut.
ITTerminalControl::D isconnectTerminal
Le terminal doit faire tout ce qui est nécessaire pour déconnecter le terminal du reste du graphique. En règle générale, cela implique de supprimer tous les filtres des terminaux du graphe et de définir l’état du terminal sur TS_NOTINUSE.
ITTerminalControl::RunRenderFilter
Le terminal doit simplement retourner E_NOTIMPL.
ITTerminalControl::StopRenderFilter
Le terminal doit simplement retourner E_NOTIMPL.