web-dev-qa-db-fra.com

RTMP vs RTSP / RTP: Que choisir pour un livestream interactif?

Si vous essayez de développer une application de diffusion en direct interactive, vous comptez sur une latence ultra faible (en temps réel). Par exemple pour une vidéoconférence ou un laboratoire distant.

Les deux protocoles qui devraient convenir à ces circonstances sont:

  • RTSP, lors de la transmission des données via RTP
  • RTMP

* WebRTC: Comme j'essaie de donner à un public plus large la possibilité d'interagir les uns avec les autres, WebRTC ne convient pas. Parce que pour autant que je sache, il n'est pas conçu pour un public plus large.

Mes questions:

  1. Lequel dois-je choisir pour ce cas d'utilisation? RTSP/RTP ou RTMP?

  2. Quel protocole fournit de meilleurs résultats concernant latence de bout en bout, le temps de démarrage de la session?

  3. Lequel consomme le plus de ressources matérielles?

  4. RTMP semble utiliser une connexion persistante TCP. Mais quel protocole est utilisé pour la transmission? Ce ne peut pas être TCP, car cela ne pourrait pas garantir une latence en temps réel?

  5. Quels sont en général les avantages et les inconvénients de l'utilisation de l'un ou l'autre des protocoles?

Je n'ai trouvé aucune comparaison de ces deux protocoles dans des articles ou des livres scientifiques. Seulement, la célèbre application mobile de streaming en direct Periscope utilise RTMP.

D'autres applications comme Instagram ou Facebook fournissent par exemple une interaction textuelle avec le streamer. Si les développeurs veulent construire la prochaine "application de tueur" basée sur des flux interactifs en direct: je pense que cette question est essentielle pour répondre.

streamingrtsprtmprtplive-streaming
10
Joey

Vous faites beaucoup d'hypothèses dans votre réponse.

WebRTC: Comme j'essaie de donner à un public plus large la possibilité d'interagir les uns avec les autres, WebRTC ne convient pas. Parce que pour autant que je sache, il n'est pas conçu pour un public plus large.

Ce n'est tout simplement pas vrai. WebRTC ne sait pas ou ne se soucie pas de la façon dont vous structurez vos applications côté serveur. Il existe de nombreux services standard pour gérer les appels de grands groupes et la distribution vidéo à faible latence via WebRTC.

Vous devez également savoir que pour les flux multimédias, WebRTC est RTP sous le capot).

Il ne peut pas s'agir de TCP, car cela ne pourrait pas garantir une latence en temps réel?

Bien sûr que oui. Il y a des frais généraux avec TCP, mais rien ne vous empêche de l'utiliser dans un scénario en temps réel. La surcharge avec TCP est minimale.

UDP est traditionnellement utilisé pour ce type de scénarios, car la fiabilité n'est pas requise, mais cela ne signifie pas TCP ne peut pas être utilisé de manière presque aussi performante.

RTMP

RTMP est un protocole mort pour Flash. Aucun navigateur ne le prend en charge. D'autres clients ne le prennent en charge que pour des raisons héritées. Vous ne devriez pas l'utiliser pour quelque chose de nouveau à l'avenir.

Seulement, la célèbre application mobile de streaming en direct Periscope utilise RTMP.

Eh bien, ce n'est pas une raison pour faire grand-chose.

  1. Quel protocole offre de meilleurs résultats en termes de latence de bout en bout, de temps de démarrage de session?

WebRTC

  1. Lequel consomme le plus de ressources matérielles?

Ce n'est pas la bonne question à poser. Votre surcharge dans presque toutes les autres parties de l'application va être bien plus importante que la surcharge de transport du protocole utilisé pour la distribution.

La vraie liste de choses auxquelles vous devez penser:

  • Compatibilité client. Quel type de clients devez-vous soutenir?
  • Avez-vous vraiment besoin d'une faible latence partout? Comprenez-vous les compromis que vous faites avec cette demande? Êtes-vous prêt à détruire tout sens de la qualité et de la fiabilité de la vidéo pour tous vos utilisateurs si seulement une poignée d'entre eux vont être interactifs?
  • Quel est ton budget? Les solutions de distribution standard sont beaucoup moins chères. Si vous pouvez pousser votre flux vers YouTube pour les utilisateurs non interactifs, vous pouvez vous économiser une tonne d'argent. Si vous ne pouvez pas utiliser l'infrastructure existante, préparez-vous à dépenser des montagnes d'argent.
  • Quelles sont vos exigences de latence réelles? Êtes-vous prêt à réduire le nombre de personnes pouvant utiliser votre application lorsque ces exigences de latence ne peuvent pas être satisfaites sur des réseaux et des appareils mobiles plus fous?
  • Quelles sont vos exigences de qualité?
  • Où allez-vous transcoder la vidéo en une variété de débits?
  • Vos téléspectateurs ont-ils besoin d'une visualisation adaptative du débit binaire?
  • Avez-vous besoin de diffuser des flux vers d'autres plates-formes simultanément?
  • Avez-vous besoin d'enregistrer le streaming pour regarder à la demande ou remonter dans le temps?

Vous pouvez également trouver mon article ici utile: https://stackoverflow.com/a/37475943/362536

En bref, vérifiez vos hypothèses. Comprenez les compromis. Prenez des décisions basées sur des informations réelles et non sur des généralisations radicales.

18
Brad