Substitution de protocole

[La fonctionnalité associée à cette page, le Kit de développement logiciel (SDK) Windows Media Format 11, est une fonctionnalité héritée. Il a été remplacé par le lecteur source et l’enregistreurrécepteur. Le lecteur source et l’enregistreur récepteur ont été optimisés pour Windows 10 et Windows 11. Microsoft recommande vivement que le nouveau code utilise le lecteur source et l’enregistreur récepteur au lieu du Kit de développement logiciel (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 par lequel l’objet lecteur découvre le meilleur protocole de streaming 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)
• Hypertext Transfer Protocol (HTTP)
• Microsoft Media Server (MMS)

Les protocoles RTSP et MMS sont tous deux disponibles dans deux versions, l’une utilisant UDP comme protocole de remise sous-jacent et l’autre utilisant TCP.

L’objet reader 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 grâce à 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ù l’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 :

1. RTSPU (RTSP à l’aide d’UDP)
2. RTSPT (RTSP avec TCP)
3. MMSU (MMS avec UDP)
4. MMST (MMS avec TCP)
5. 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 provenant d’un lecteur du Kit de développement logiciel (SDK) au format Windows Media, car RTSP est le protocole de diffusion en continu préféré. Windows Media Services version 4.1 et 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 que le lecteur a ouvert un fichier, vous pouvez interroger le protocole qu’il utilise en appelant la méthode IWMReaderAdvanced2::GetProtocolName sur le lecteur. Lorsque 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 renvoie la chaîne « Cache ».

Pour obtenir les noms de tous les protocoles 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 l’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’y a 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, cela peut être utile pour les tests.