Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
[La fonctionnalité associée à cette page, sdk Windows Media Format 11, est une fonctionnalité héritée. Il a été remplacé par lecteur source et enregistreur récepteur. lecteur source et enregistreur récepteur ont été optimisés pour Windows 10 et Windows 11. Microsoft recommande vivement que le nouveau code utilise lecteur source et enregistreur récepteur au lieu d'SDK Windows Media Format 11, lorsque cela est possible. Microsoft suggère que le code existant qui utilise les API héritées soit réécrit pour utiliser les nouvelles API si possible.]
La substitution de protocole est un processus dans lequel l’objet lecteur découvre le meilleur protocole de diffusion en continu disponible à partir d’un serveur. Le lecteur utilise la substitution de protocole chaque fois qu’il ouvre une URL qui contient un schéma « mms ».
Le lecteur prend en charge plusieurs protocoles :
- Protocole RTSP (Real Time Streaming Protocol)
- Protocole HTTP (Hypertext Transfer Protocol)
- Microsoft Media Server (MMS)
Les protocoles RTSP et MMS sont tous deux disponibles en deux versions, l’une utilisant UDP comme protocole de remise sous-jacent et l’autre à l’aide de TCP.
L’objet lecteur utilise toujours TCP pour les commandes de contrôle de lecture, mais il peut utiliser TCP ou UDP pour la remise du contenu diffusé en continu. UDP est préféré pour la distribution de contenu, car il impose moins de surcharge de bande passante que TCP. Le protocole TCP garantit un transport fiable via l’utilisation de « circuits virtuels », mais le coût de cette opération signifie que TCP n’est pas aussi adapté aux flux multimédias numériques, où une utilisation efficace de la bande passante est plus importante que les paquets perdus occasionnellement.
Lorsqu’une URL spécifie « mms:// », le lecteur tente d’utiliser les protocoles suivants pour la remise des données, dans l’ordre suivant :
- RTSPU (RTSP à l’aide d’UDP)
- RTSPT (RTSP à l’aide de TCP)
- MMSU (MMS à l’aide d’UDP)
- MMST (MMS à l’aide de TCP)
- HTTP
HTTP est un protocole unidirectionnel basé sur TCP et est le protocole utilisé par les serveurs Web. La diffusion en continu avec HTTP est moins efficace que l’utilisation de RTSP. Toutefois, la plupart des pare-feu sont configurés pour accepter les requêtes HTTP, alors qu’ils rejettent généralement d’autres protocoles de streaming.
La série Windows Media Services 9 dans Microsoft Windows Server 2003 rejette toutes les demandes MMSU ou MMST d’un lecteur du SDK Windows Media Format, car RTSP est le protocole de diffusion en continu préféré. Windows Media Services version 4.1 et versions antérieures ne prennent pas en charge RTSP. Dans ce cas, l’objet lecteur revient à MMSU ou HTTP.
La substitution de protocole ne s’applique pas si le schéma d’URL fournit un protocole spécifique, tel que « rtspu:// » pour RTSPU ou « https:// » pour HTTP. Si le schéma d’URL est « rtsp:// », le lecteur essaie RTSPU et RTSPT, mais pas d’autres.
Une fois le lecteur ouvert un fichier, vous pouvez interroger le protocole qu’il utilise en appelant la méthode IWMReaderAdvanced2 ::GetProtocolName sur le lecteur. Pendant que le contenu est diffusé en continu ou téléchargé, cette méthode retourne le nom dès que le contenu est complètement mis en cache, la méthode GetProtocolName retourne la chaîne « Cache ».
Pour obtenir les noms de tous les protocoles de serveur Windows Media pris en charge par le lecteur, appelez la méthode IWMReaderNetworkConfig ::GetSupportedProtocolName sur le lecteur. Vous pouvez désactiver un ou plusieurs protocoles dans la liste de substitution de protocole du lecteur, à l’aide de interface IWMReaderNetworkConfig. Par exemple, la méthode IWMReaderNetworkConfig ::SetEnableTCP active ou désactive les protocoles TCP, et IWMReaderNetworkConfig ::SetEnableUDP active ou désactive les protocoles UDP. Ces méthodes s’appliquent uniquement à la substitution de protocole ; les protocoles sont toujours disponibles si le schéma d’URL contient un protocole spécifique. Il n’existe généralement aucune raison de désactiver l’un des protocoles utilisés dans la substitution de protocole ; cela peut dégrader les performances. Toutefois, il peut être utile pour les tests.