Le RTSP est un protocole de signalisation simple qu'ils ne peuvent remplacer par rien depuis de nombreuses années déjà, et il faut admettre qu'ils n'essaient pas vraiment.
Par exemple, nous avons une caméra IP qui prend en charge RTSP. Quiconque a déjà testé le trafic avec un câble Sharkwire vous dira que d'abord il y a DESCRIBE, puis PLAY, puis le trafic commence à couler directement via RTP ou enveloppé dans le canal TCP par exemple.
Un schéma typique d'établissement d'une connexion RTSP ressemble à ceci:
Il est concevable que le support du protocole RTSP ne soit pas nécessaire pour les navigateurs et soit à peu près autant utilisé que la cinquième roue, par conséquent les navigateurs ne sont pas pressés de l'implémenter à grande échelle, et cela n'arrivera presque jamais. D'un autre côté, les navigateurs pourraient créer des connexions TCP directes, ce qui résoudrait la tâche, mais maintenant, il se heurte à des problèmes de sécurité: avez-vous déjà vu un navigateur qui permettrait à un script d'utiliser directement les protocoles de transport?
Mais les gens exigent que les flux soient disponibles dans "n'importe quel navigateur sans installer de logiciel supplémentaire", et les startuppers écrivent sur leurs sites Web, "vous n'avez rien à installer, cela fonctionnera dans tous les navigateurs prêts à l'emploi", quand ils souhaitez afficher un flux provenant d'une caméra IP.
Dans cet article, nous allons explorer comment cela peut être réalisé. Et comme l'année à venir contient un chiffre rond, ajoutons de l'actualité à notre article et collons-y une étiquette avec 2020, d'autant plus qu'il en est vraiment ainsi.
Alors, quelles technologies d'affichage vidéo pour une page Web doivent être oubliées en 2020? C'est Flash dans le navigateur. C'est mort. Il n'existe plus, rayez-le de la liste.
Trois méthodes utiles
Les outils qui vous permettront de regarder un flux vidéo dans votre navigateur aujourd'hui sont:
- WebRTC
- Hls
- Websocket + MSE
Quel est le problème avec WebRTC
En deux mots: elle est gourmande en ressources et compliquée.
Vous allez le faire signe, "Que voulez-vous dire par gourmand en ressources?", Comme les processeurs sont puissants de nos jours, la mémoire est bon marché, alors quel est le problème? Eh bien, tout d'abord, c'est le cryptage obligatoire de tout le trafic même si vous n'en avez pas besoin. Deuxièmement, WebRTC est une connexion bidirectionnelle compliquée et un échange de rétroaction d'égal à égal sur la qualité du canal (homologue à serveur, dans ce cas): à chaque instant, un débit binaire est calculé, des pertes de paquets détectées, des décisions sur leur redirection prise, et la synchronisation audio-vidéo est calculée par rapport à tout cela, la soi-disant lèvresync, qui fait coïncider les lèvres de l'orateur avec leurs mots. Tous ces calculs, ainsi que le trafic entrant sur le serveur, allouent et libèrent des gigaoctets de RAM en temps réel, et si quelque chose se passe mal, un serveur de 256 gigaoctets avec un processeur à 48 cœurs se mettra facilement en rotation malgré tous les gigaherzs, nanomètres et DDR 10 à bord.
C'est donc une sorte de chasse aux écureuils avec un missile Iskander. Tout ce que nous devons aspirer, c'est un flux RTSP, puis l'afficher, et ce que WebRTC dit, "Oui, allez, mais vous devrez payer pour cela."
Pourquoi WebRTC est bon
La latence. C'est vraiment bas. Si vous êtes prêt à sacrifier les performances et la complexité pour la faible latence, WebRTC est la variante la plus appropriée pour vous.
Pourquoi HLS est bon
En deux mots: ça peut fonctionner partout
HLS est un tout-terrain lent dans le monde de l'affichage de contenu en direct. Il peut fonctionner partout grâce à deux choses: le transport HTTP et le patronage d'Apple. En effet, le protocole HTTP est omniprésent, je peux sentir sa présence même lorsque j'écris ces lignes. Ainsi, peu importe où vous vous trouvez et quelle ancienne tablette vous utilisez pour surfer sur le net, HLS (HTTP Live Streaming) vous parviendra et vous livrera la vidéo sur votre écran.
C'est assez bien, mais ...
Pourquoi HLS est mauvais
La latence. Il existe par exemple des projets de vidéosurveillance de chantier. Une installation est en construction depuis des années, et pendant tout ce temps, la mauvaise caméra enregistre des vidéos du chantier de construction jour et nuit, 24/7. Ceci est un exemple d'une situation où la faible latence n'est pas nécessaire.
Un autre exemple est celui des sangliers. De vrais sangliers. Les agriculteurs de l'Ohio souffrent d'une invasion de sangliers qui se nourrissent des cultures et les piétinent comme des sauterelles, ce qui constitue une menace pour le bien-être financier des fermes. Des startuppers entreprenants ont lancé un système de vidéosurveillance à partir de caméras RTSP qui surveille le terrain en temps réel et déclenche un piège lorsque les intrus envahissent. Dans ce cas, la faible latence est d'une importance critique, et si HLS est utilisé (avec une latence de 15 secondes), les verrats s'enfuiront avant l'activation du piège.
Voici un autre exemple: des présentations vidéo où quelqu'un vous montre un produit et attend une réponse rapide. Dans le cas d'une latence élevée, ils vous montreront le produit sur l'appareil photo, puis demanderont: «Alors, comment aimez-vous ça?», Et cela ne vous parviendra qu'en 15 secondes. En 15 secondes, le signal peut se déplacer vers la Lune et revenir 12 fois. Non, nous ne voulons pas d'une telle latence. Cela ressemble plutôt à une vidéo préenregistrée qu'à Live. Mais la vidéo préenregistrée, car c'est ainsi que HLS fonctionne: il enregistre des parties d'une vidéo sur un disque ou dans la mémoire du serveur, et le lecteur télécharge les parties enregistrées. C'est ainsi que HTTP Live fonctionne, ce qui n'est pas du tout Live.
Pourquoi cela arrive-t-il? La présence mondiale du protocole HTTP et sa simplicité entraînent sa lenteur car HTTP n'était pas initialement destiné au téléchargement et à l'affichage rapides de milliers de gros fragments vidéo (segments HLS). Ils sont bien sûr téléchargés et joués avec une haute qualité, mais très lentement: cela prend 15 secondes ou plus pour qu'ils soient téléchargés, mis en mémoire tampon et décodés.
Il convient de noter ici qu'Apple a annoncé son HLS Low Latency à l'automne 2019, mais c'est déjà une autre histoire. Jetons un regard plus détaillé sur leurs résultats plus tard. Et maintenant, nous avons également MSE en stock.
Pourquoi MSE est bon
Media Source Extension est une prise en charge native de la lecture de vidéos par paquets dans le navigateur. Il peut être appelé lecteur natif pour H.264 et AAC, sur lequel vous pouvez alimenter des segments vidéo et qui n'est pas lié à un protocole de transport, contrairement à HLS. Pour cette raison, vous pouvez choisir le transport via le protocole Websockets. En d'autres termes, les segments ne seront plus téléchargés en utilisant l'ancienne technologie Request-Response (HTTP), mais se déverseront facilement via la connexion Websockets qui est presque un canal TCP direct. Ceci est d'une grande utilité en ce qui concerne la réduction des retards qui peuvent devenir aussi bas que 3-5 secondes. Une telle latence n'est pas fantastique mais convient à la plupart des projets qui ne nécessitent pas de temps réel difficile. La complexité et l'intensité des ressources sont également relativement faibles car un canal TCP est ouvert et presque les mêmes segments HLS le traversent, qui sont collectés par le lecteur et envoyés pour être lus.
Pourquoi MSE est mauvais
Cela ne peut pas fonctionner partout. Comme pour WebRTC, sa pénétration dans les navigateurs est plus faible. Les iPhones (iOS) ont une histoire particulièrement remarquable d'échec de lecture de MSE, ce qui rend MSE difficilement approprié comme seule solution pour une startup.
Il est entièrement disponible dans les navigateurs suivants: Edge, Firefox, Chrome, Safari, navigateur Android, Opera Mobile, Chrome pour Android, Firefox pour Android, navigateur UC pour Android.
La prise en charge limitée de MSE est apparue dans iOS Safari il y a assez peu de temps, à commencer par iOS 13.
Jambe RTSP
Nous avons discuté de la livraison dans la direction du serveur vidéo> du navigateur. En plus de cela, vous aurez également besoin de ces deux choses:
1) Pour livrer votre vidéo de la caméra IP au serveur.
2) Pour convertir la vidéo dans l'un des formats / protocoles décrits ci-dessus.
C'est là que le côté serveur entre en jeu.
Ta-dah ... Rencontrez Web Call Server 5 (ou simplement WCS pour vos amis). Quelqu'un doit recevoir le trafic RTSP, désemballer correctement la vidéo, la convertir en WebRTC, HLS ou MSE, de préférence sans être surcompressé par le transcodeur, et l'envoyer vers le navigateur sous une forme présentable, non corrompu par des artefacts et des gels.
La tâche n'est pas compliquée à première vue, mais il peut y avoir tellement d'embûches cachées, de caméras chinoises et de nuances de conversion derrière elle que c'est vraiment horrible. Ce n'est pas possible sans hacks en fait, mais cela fonctionne et fonctionne bien. En production.
Le schéma de livraison
En conséquence, un schéma complet de livraison de contenu RTSP avec conversion sur un serveur intermédiaire commence à prendre forme.
L'une des questions les plus fréquemment posées par nos collègues indiens est: «Est-ce possible? Directement, sans serveur? ”. Non, ce n'est pas le cas; vous aurez besoin du côté serveur qui fera le travail. Dans le cloud, sur le matériel, sur corei7 dans votre balcon, mais vous ne pouvez pas vous en passer.
Revenons à notre année 2020
Alors, voici la recette pour cuisiner un RTSP dans votre navigateur:
- Prenez un nouveau WCS (Web Call Server) .
- Ajoutez WebRTC, HLS ou MSE au goût.
Servez-les sur la page Web.
Bon repas!
Non, ce n'est pas encore tout.
Les neurones enquêteurs voudront certainement poser cette question: «Comment? Vraiment, comment cela peut-il être fait ? À quoi cela ressemblera-t-il dans le navigateur? "
Nous aimerions attirer votre attention sur le lecteur WebRTC minimaliste assemblé comme un effort de table de cuisine.
1) Connectez le script principal de l'API flashphoner.js et le script my_player.js, que nous allons créer un peu plus tard, à la page Web.
<script type="text/javascript" src="../../../../flashphoner.js"></script> <script type="text/javascript" src=my_player.js"></script>
2) Initialiser l'API dans le corps de la page Web
<body onload="init_api()">
3) Ajoutez div, qui servira de conteneur pour les vidéos, à la page. Définissez les tailles et la limite pour cela.
<div id="myVideo" style="width:320px;height:240px;border: solid 1px"></div>
4) Ajoutez le bouton Lecture, le clic sur qui initialisera la connexion au serveur et commencera à lire la vidéo
<input type="button" onclick="connect()" value="PLAY"/>
5) Créons maintenant le script my_player.js qui contiendra le code principal de notre lecteur. Décrire les constantes et les variables
var SESSION_STATUS = Flashphoner.constants.SESSION_STATUS; var STREAM_STATUS = Flashphoner.constants.STREAM_STATUS; var session;
6) Initialiser l'API lorsqu'une page HTML est chargée
function init_api() { console.log("init api"); Flashphoner.init({ }); }
7) Connectez-vous au serveur WCS via WebSocket. Pour que tout fonctionne correctement, remplacez "wss: //demo.flashphoner.com" par votre adresse WCS
function connect() { session = Flashphoner.createSession({urlServer: "wss://demo.flashphoner.com"}).on(SESSION_STATUS.ESTABLISHED, function(session){ console.log("connection established"); playStream(session); }); }
8) Après cela, transmettez les deux paramètres suivants, "nom" et "affichage", où "nom" est l'URL RTSP du flux en cours de lecture, et "affichage" est l'élément de myVideo dans lequel notre lecteur sera installé. Définissez ici également l'URL de votre flux, au lieu du nôtre.
function playStream() { var options = {name:"rtsp://b1.dnsdojo.com:1935/live/sys2.stream",display:document.getElementById("myVideo")}; var stream = session.createStream(options).on(STREAM_STATUS.PLAYING, function(stream) { console.log("playing"); }); stream.play(); }
Enregistrez les fichiers et essayez de lancer le lecteur. Votre flux RTSP est-il lu?
Lorsque nous l'avons testé , celui-ci a été joué: rtsp: //b1.dnsdojo.com: 1935 / live / sys2.stream.
Et voici à quoi ça ressemble:
Le joueur avant de cliquer sur le bouton Lecture
Le joueur avec une vidéo lancée
Il n'y a pas beaucoup de code du tout:
HTML
<!DOCTYPE html> <html lang="en"> <head> <script type="text/javascript" src="../../../../flashphoner.js"></script> <script type="text/javascript" src=my_player.js"></script> </head> <body onload="init_api()"> <div id="myVideo" style="width:320px;height:240px;border: solid 1px"></div> <br/><input type="button" onclick="connect()" value="PLAY"/> </body> </html>
Javascript
demo.flashphoner.com est utilisé comme serveur. Le code complet de l'exemple est disponible ci-dessous, au bas de la page contenant les liens.
Bon streaming!
Les liens
Code joueur sur github
Intégration d'un lecteur RTSP dans une page Web ou une application mobile