Réponse courte : choisissez le protocole que le côté réception peut réellement accepter. SRT est une option de contribution lorsque les deux extrémités le prennent en charge et que le chemin est configuré ; RTMP reste un transfert courant d’un encodeur vers une plateforme ou un serveur d’ingestion. La lecture et la diffusion aux spectateurs demeurent des tâches aval configurées séparément.
Commencez par le récepteur, puis choisissez le transfert
| Point de décision | Chemin SRT | Chemin RTMP |
|---|---|---|
| Récepteur | Un récepteur de contribution compatible SRT que vous contrôlez ou qui vous a été attribué | Un point de terminaison d’ingestion RTMP ou une URL de plateforme fournie pour la publication |
| Transport | Session SRT basée sur UDP ; le mode live comprend des contrôles de temporisation et de retransmission | Session RTMP basée sur TCP vers le point de terminaison configuré |
| Question réseau | Les deux pairs peuvent-ils se joindre et leurs réglages de mode, de latence et de phrase secrète concordent-ils ? | L’encodeur peut-il joindre l’hôte et l’URL/la clé correspondent-elles au contrat du point de terminaison ? |
| Question codec | Validez séparément le conteneur et les codecs acceptés par le récepteur | Validez séparément le profil audio/vidéo accepté par la cible |
| Tâche suivante utile | Contribution vers un workflow d’exploitation ou de production | Publication vers un service d’ingestion ou un RTMP Server configuré |
Trois décisions courantes
- La plateforme fournit uniquement une URL et une clé de flux : publiez en RTMP selon ce contrat.
- Votre équipe contrôle un récepteur SRT : utilisez SRT lorsque le mode, host:port, la latence et tout Stream ID/phrase secrète ont été convenus aux deux extrémités.
- La contribution SRT se termine sur une plateforme RTMP/RTMPS : validez séparément la contribution SRT et le transfert de publication vers la plateforme.
Le mode live de SRT est conçu autour d’une fenêtre de latence configurée et du retour du récepteur ; une fenêtre plus grande peut laisser davantage de temps à la récupération, mais reste un choix de déploiement et non une promesse de meilleure image. La compatibilité RTMP est tout aussi spécifique au point de terminaison. Une plateforme qui exige une URL RTMP ou RTMPS décide du transfert final, même si le segment de contribution emploie SRT ailleurs.
Ce qui change dans l’exploitation
| Avant la première connexion | À consigner |
|---|---|
| SRT | Mode caller/listener/rendezvous ; host:port ; latence ; Stream ID ou phrase secrète lorsqu’ils sont utilisés ; conteneur et codecs vidéo/audio. |
| RTMP | URL d’ingestion complète, application/chemin et clé ; profil déclaré par le récepteur, souvent H.264/AAC lorsque le point de terminaison l’exige ; et son contrôle de santé du flux. |
Ne laissez pas des identifiants dans des captures d’écran, journaux de chat ou enregistrements de test.
Le chiffrement SRT et RTMPS répondent à des questions de sécurité de transport différentes : SRT peut être configuré avec chiffrement, tandis que RTMPS est RTMP transporté sur TLS. Une destination RTMPS ne décrit pas les options d’ingestion d’un RTMP Server distinct.
Testez un chemin de contribution
Utilisez la même source préparée pour l’un ou l’autre onglet : figez le format du programme, notez les réglages des codecs vidéo et audio et donnez au publisher accès au point de terminaison de test sélectionné. Démarrez une session de protocole, confirmez l’état du publisher, inspectez l’aperçu, puis vérifiez la sortie aval si le workflow en utilise une.
DÉMOS DE PROTOCOLES
Choisissez un protocole à tester
Chaque démo est lancée manuellement et conserve sa propre durée de validité temporaire. Utilisez des réglages source identiques pour comparer les flux ; cette page n'exécute pas de mesure contrôlée de latence.
Démo SRT en direct
Essayer une connexion SRT en direct
Créez une connexion temporaire pendant une heure. Envoyez votre flux à l’adresse de publication en mode Caller, en laissant l’ID de flux vide. regardez-le dans Multiview ci-dessous, ou connectez votre récepteur à l’adresse de réception en mode Caller.
Le résultat confirme que la source sélectionnée a atteint ce chemin temporaire et son aperçu. C’est un contrôle de configuration, pas un benchmark comparatif ; il ne classe donc ni la latence, ni la qualité, ni la fiabilité. Répétez une configuration modifiée comme un nouveau test et conservez les journaux du récepteur ou les données de connexion visibles à l’opérateur.
Où Callaba intervient
Le RTMP Server de Callaba peut donner aux publishers et receivers des règles d’accès distinctes et afficher une activité visible par l’opérateur. Un RTMP Server Guest peut au contraire être ouvert sans règles d’accès prédéfinies. Son SRT Server est la ressource de contribution correspondante pour un workflow SRT compatible. L’observation dans le navigateur et la lecture pour les spectateurs utilisent des modules configurés séparément ; une URL de publication RTMP n’est pas lisible dans un navigateur.
Étapes suivantes
- Pour un écouteur RTMP configuré, consultez RTMP Server et ses contrôles d’accès et de cycle de vie.
- Pour un récepteur de contribution SRT, consultez SRT Server.
- Pour un pont explicite, utilisez le chemin documenté de la passerelle de contribution RTMP seulement après avoir confirmé les deux points de terminaison.
