RTMP, SRT ou WHIP : choisir son protocole d’ingest

Avant la comparaison : l'erreur qui coûte leur première heure à beaucoup de gens se trouve dans l'URL SRT, et elle ne produit aucun message d'erreur. Lisez la section suivante, même si vous sautez tout le reste.

La panne qui ressemble à « il ne se passe rien »

Une URL d'ingest SRT contient un streamid qui ressemble à ceci : #!::r=live/sk_srt_…,m=publish. Ces caractères — #, !, :, , — sont exactement ceux qu'une personne soigneuse encode en pourcentage par réflexe. Ne le faites pas. La bibliothèque SRT ne décode pas le streamid ; elle transmet les octets tels quels au serveur. Un streamid encodé arrive donc comme un nom de flux commençant par %23, le serveur traite la connexion comme une demande de lecture et non de publication, et rien ne vous est signalé. Votre encodeur affiche une connexion saine. La carte du flux n'affiche aucun signal. Il n'y a d'erreur nulle part.

Collez l'URL SRT exactement telle que l'API la renvoie. dcast la fournit sous sa forme littérale, prête à publier, dans data.ingest.srt de GET /api/v1/streams/:id, et la même valeur dans data.ingest.srtDisplay, qui n'existe que comme alias pour les anciennes intégrations. L'une comme l'autre se colle directement dans votre encodeur, sans rien réécrire.

Ce que dcast accepte

Une carte de flux peut être alimentée par n'importe laquelle de ces sources. Vous choisissez pour chaque carte, et ce choix ne change pas l'image que reçoivent vos spectateurs.

Le nom d'hôte est toujours a.dcast.pro — le point d'entrée du pool de routage, jamais le nom d'un serveur précis. C'est voulu : l'adresse que vous avez configurée une fois continue de fonctionner quand le flux atterrit sur une autre machine.

RTMP : celui qui marche toujours

RTMP est ancien, et c'est là tout son avantage. Chaque encodeur, chaque caméra dotée d'un mode streaming, chaque application mobile et chaque boîtier qu'on peut vous tendre sur place sait envoyer du RTMP sans autre réglage qu'un serveur et une clé. Si vous diffusez depuis un réseau stable et que vous ne cherchez pas à résoudre un problème précis, RTMP est le bon choix et vous pouvez arrêter votre lecture ici.

Son point faible, c'est ce qui se passe quand le réseau n'est pas stable. RTMP fonctionne sur TCP, et TCP gère les pertes en retransmettant et en attendant. Sur une bonne liaison, c'est invisible. Sur une liaison avec de vraies pertes de paquets, non : le flux accumule une latence qu'il ne rattrape jamais, ou il se fige, et la reprise va de l'élégante à la déconnexion selon l'encodeur.

Si votre encodeur demande le serveur et la clé séparément, coupez l'URL au dernier slash : serveur rtmp://a.dcast.pro/live, clé sk_rtmp_…. (Les clés de flux portent en préfixe le protocole pour lequel la carte a été créée — sk_rtmp_, sk_srt_, sk_webrtc_ —, la clé que vous collez doit donc correspondre à la porte à laquelle vous frappez.)

SRT : celui des mauvais réseaux

SRT existe pour le cas que RTMP gère mal : une liaison avec des pertes de paquets que vous ne pouvez pas corriger, c'est-à-dire en pratique les réseaux mobiles, le Wi-Fi public des salles et tout ce qui traverse une longue distance.

Le principe, c'est un budget de latence fixe. Au lieu de retransmettre jusqu'à ce que le paquet arrive, quel que soit le temps que ça prend, SRT garde une mémoire tampon de la taille choisie et ne redemande les paquets perdus que tant qu'il reste le temps de les remettre à leur place. Les paquets qui ne peuvent pas arriver à temps sont abandonnés plutôt que de retarder tout ce qui suit. Résultat : un flux au délai prévisible, qui se dégrade en douceur sous les pertes, au lieu d'un délai imprévisible et de blocages.

Ce tampon, c'est le paramètre latency, exprimé en millisecondes. Les URL émises par dcast indiquent 500 ms, et vous pouvez monter jusqu'à 7000. Le compromis est direct et il n'existe pas de réglage miracle : une valeur plus élevée résiste à des pertes plus fortes et ajoute exactement ce délai. Si votre flux perd des paquets, augmentez-la.

Descendre sous 500 est la seule chose qui ne marchera pas, et mieux vaut savoir pourquoi que le découvrir. Notre ingest déclare lui-même 500 ms, et une connexion SRT retient la plus grande des deux valeurs annoncées par chaque extrémité — un encodeur qui demande 80 ms obtient donc quand même 500. Ce chiffre est un plancher, pas seulement une valeur par défaut.

Deux autres réglages SRT méritent d'être connus. Le mode — dcast émet des URL en mode caller, ce qui signifie que votre encodeur ouvre la connexion vers l'extérieur : c'est ce qui fonctionne derrière un routeur sans redirection de port. listener et rendezvous existent pour les configurations qui en ont besoin. Et la passphrase — SRT peut chiffrer la liaison ; si vous en définissez une, elle doit comporter au moins dix caractères.

WHIP : celui du navigateur

WHIP est la façon dont une source WebRTC publie. Au lieu d'une URL de flux, vous envoyez une offre SDP à un endpoint HTTPS et une connexion pair à pair s'établit. dcast renvoie cet endpoint avec les autres sur la carte du flux.

Utilisez-le quand votre source est un navigateur — un invité qui n'a rien installé, une interface de contrôle web, un partage d'écran — ou quand il vous faut une latence de contribution inférieure à ce qu'un chemin segmenté peut offrir. Les encodeurs compatibles WHIP le proposent comme service de streaming dans lequel vous collez l'URL renvoyée telle quelle ; il n'y a pas de champ séparé pour la clé de flux, puisque la clé figure déjà dans l'URL.

Sa limite : WebRTC est plus exigeant à faire tourner qu'un envoi TCP. Il est plus sensible aux réseaux restrictifs et moins universellement pris en charge par les encodeurs matériels que RTMP.

Votre choix de protocole ne change pas votre image

C'est la partie qui épargne beaucoup de tests. Quel que soit le protocole qui achemine votre flux, il est normalisé dans une forme interne unique avant toute autre étape, et l'échelle d'encodage qui tourne ensuite est identique. Les mêmes paliers, les mêmes plafonds de débit, le même intervalle d'images clés de 2 secondes, les mêmes segments de 4 secondes contenant chacun deux images clés.

Autrement dit : un flux SRT et un flux RTMP portant la même source au même débit produisent le même résultat. Choisir SRT ne vous offre pas une meilleure image, et choisir RTMP ne vous en coûte pas. Choisissez en fonction du comportement de votre réseau : c'est la seule chose sur laquelle ce choix agit vraiment.

La fréquence d'images est elle aussi décidée de notre côté et non par le protocole, et de la même façon pour les trois : au moment où nous écrivons ces lignes, l'échelle live est encodée à 30 fps, quoi que vous envoyiez.

Ne construisez pas l'URL d'ingest à la main

Chaque adresse d'ingest que vous donne dcast est émise par l'API pour une carte de flux précise, et chacune de ses parties a un rôle. GET /api/v1/streams/:id les renvoie toutes ensemble dans data.ingest, et la bonne méthode consiste à les copier de là à chaque fois plutôt que de garder une URL dans un document et d'y modifier la clé.

Le nom d'hôte est le point d'entrée du pool et non le nom d'une machine : il reste valable même si votre flux est servi depuis ailleurs la semaine prochaine. La clé identifie votre carte. En SRT, le streamid porte en plus le mode — c'est m=publish qui fait de la connexion une publication et non une lecture —, et c'est précisément pour cela que la panne d'encodage décrite en tête de cet article est si silencieuse : en abîmant le streamid, vous n'avez pas envoyé une requête malformée, vous avez envoyé une requête parfaitement valide pour regarder un flux qui n'existe pas.

Deux habitudes évitent presque tout cela. Copiez l'URL entière, y compris tout ce qui suit le ?, en une seule fois. Et quand un encodeur tient à avoir des champs séparés pour le serveur et la clé, coupez au dernier slash et collez les deux moitiés au lieu d'en retaper une.

Si vous faites une intégration plutôt qu'une configuration manuelle, demandez les cibles d'ingest au moment de vous en servir au lieu de les mettre en cache, pour la même raison : la valeur qu'on vous donne est juste maintenant, et la redemander ne coûte presque rien.

Chiffrer la liaison

SRT peut chiffrer le flux entre votre encodeur et nous à l'aide d'une passphrase. Cela vaut la peine de l'activer dès que la liaison traverse un réseau que vous ne maîtrisez pas — le Wi-Fi invités d'une salle, un hôtel, une connexion partagée sur un salon —, car sur ces réseaux le flux de contribution est la seule chose que vous ne pouvez vraiment pas refaire si quelqu'un s'en mêle.

La passphrase doit comporter au moins dix caractères. Mettez la même valeur aux deux extrémités ; en cas de différence, le handshake échoue au lieu de se dégrader, et c'est le comportement souhaitable, car un basculement silencieux vers une liaison non chiffrée serait pire qu'un refus.

Le chiffrement coûte un peu de calcul à chaque extrémité et rien en qualité d'image. Si vous utilisez déjà SRT parce que le réseau n'est pas digne de confiance, le même raisonnement s'applique en général à la question de savoir s'il devrait pouvoir être lu.

Choisir, en un paragraphe

Si votre réseau est une connexion filaire dans un bâtiment que vous maîtrisez, prenez RTMP. Si vous êtes sur une connexion mobile, sur le Wi-Fi d'une salle ou si vous envoyez d'un continent à l'autre, prenez SRT et augmentez la latence jusqu'à ce que le flux soit propre. Si votre source est un navigateur web, prenez WHIP. Si le contenu existe déjà sous forme de flux ailleurs, prenez le HTTP pull et laissez-nous aller le chercher plutôt que de le rediffuser à la main. Ces quatre phrases couvrent presque tous les cas réels.

Tester l'ingest avant l'événement

Testez avec l'URL réelle de la carte de flux réelle, pas avec une URL que vous avez assemblée vous-même. La plupart des échecs de première fois viennent d'une adresse construite à la main.

Testez depuis le lieu réel, sur la connexion réelle, et à l'heure réelle si le lieu est fréquenté. Un réseau propre à neuf heures du matin et saturé à sept heures du soir, c'est le cas normal, pas l'exception.

Pour SRT en particulier, surveillez pendant le test les compteurs de pertes et de retransmissions de votre encodeur plutôt que l'image. L'image a l'air parfaite jusqu'au moment où le budget de latence est épuisé : ce sont les compteurs qui vous préviennent, pas l'image.

Et vérifiez que la carte du flux affiche bien un signal, pas seulement que votre encodeur indique « connecté ». Ce sont deux affirmations différentes, et la panne du streamid SRT décrite en tête de cet article est précisément le cas où la première est vraie et la seconde fausse.