Dès les premiers jours de travail sur le système de vidéo surveillance cloud, nous avons rencontré un problème, sans la solution duquel nous aurions pu abandonner Ivideon – c'était notre Everest, dont l'ascension a exigé beaucoup d'efforts, mais maintenant, nous avons enfin planté notre piolet au sommet du casse-tête cross-platform.
Le système de transmission audio et vidéo sur Internet ne doit pas dépendre du matériel, des clients web et des standards qu'ils supportent, et doit fonctionner correctement en présence de traducteurs d'adresses réseau et de pare-feu. L'utilisateur de la vidéo surveillance cloud souhaite accéder au service, même s'il utilise des caméras analogiques, et préfère visionner le flux vidéo en direct sur l'appareil le plus moderne.
Il est très important que l'utilisateur souhaite regarder la vidéo avec un minimum de latence. La quasi-seule possibilité de montrer une vidéo avec une faible latence dans un navigateur est d'utiliser WebRTC (communications en temps réel par le web). WebRTC est un ensemble de technologies pour la transmission en peer-to-peer de vidéo et d'audio dans les navigateurs, à l'origine conçu pour transmettre et lire des flux vidéo avec une faible latence. Pour cela, entre autres, le protocole UDP est utilisé.
Avant de vous expliquer ce que le nouveau moteur apporte à l'utilisateur, nous allons rappeler pourquoi et comment nous soutenons les technologies HLS, et pourquoi nous avons décidé d'aller de l'avant.
Moteur HLS : avantages et inconvénients
()
La technologie HLS (HTTP Live Streaming) a été développée par Apple, donc il n'est pas surprenant que son support soit apparu pour la première fois sur des appareils de cette marque. À ce jour, le contenu vidéo au format HLS peut également être lu par presque tous les décodeurs de télévision et de nombreux appareils fonctionnant sous Android.
Le moteur HLS utilise pour le streaming de données vidéo le codec vidéo bien connu H264 en association avec des flux audio AAC ou MP3. L'ensemble du flux audio et vidéo est encapsulé dans un conteneur MPEG-TS. Pour être transmis via le protocole HTTP, les informations contenues dans le flux sont divisées en fragments, décrits dans des playlists m3u8. Ces fragments, ainsi que les playlists, sont ensuite transmis par HTTP. La division en fragments implique automatiquement une latence en secondes. Cette particularité du conteneur MPEG-TS.
Le moteur HLS prend également en charge les flux multi-bitrates, Live/VOD.
Les principaux avantages de HLS :
- prise en charge intégrée dans tous les navigateurs principaux;
- facilité de mise en œuvre (par rapport à WebRTC);
- il est très pratique et efficace d'organiser des diffusions à un large public grâce à la possibilité de charger des segments une seule fois sur le CDN.
Malgré la simplicité du moteur, tout ne se passe pas aussi bien qu'il y paraît. Le principal problème est que les développeurs de lecteurs tiers se sont écartés des recommandations d'Apple, par exemple en ce qui concerne les formats audio pris en charge. En particulier, de nombreux développeurs ont commencé à ajouter la possibilité de travailler avec des flux audio populaires : vidéo mpeg2, audio mpeg2, etc. En conséquence, il a fallu créer différents formats de playlist pour différents lecteurs.
Mais l'un des plus grands problèmes du moteur HLS est le temps de latence élevé dans la transmission des données.
L'origine des "ralentissements"
La principale raison de la haute latence de HLS réside dans le fait que les programmeurs ont créé le moteur pour obtenir une qualité d'image maximale. Par conséquent, les paramètres de l'intervalle d'images utilisé et le volume du tampon de lecture ne conviennent tout simplement pas à la diffusion de vidéos en direct. En conséquence, il y a une latence assez élevée dans la transmission de la vidéo, qui peut atteindre 5 à 7 secondes.
D'une part, cela semble peu, par exemple pour ceux qui regardent un film depuis un serveur de vidéo. Mais pour les systèmes de vidéosurveillance, la latence dans la transmission de la vidéo peut avoir une grande importance.
Si vous surveillez un bureau où les employés se détachent de l'écran une fois par heure, alors une latence de 5 secondes n'a aucune importance. Mais les gens ont commencé à se plaindre, par exemple, lors de la diffusion d'un match de football, que dans le chat, quelqu'un a déjà écrit GOOOOL, mais la vidéo ne le montre pas encore :). Nous avons déjà plusieurs cas d'utilisation où Ivideon doit pratiquement remplacer Skype.
Peut-on surmonter la latence dans HLS? La réponse à cette question ressemble à un discours d'un exterminateur de rats chevronné lors d'une conférence pour des dératiseurs débutants : « On ne peut pas exterminer les rats, mais on peut réduire leur population à un minimum raisonnable ». Ainsi, concernant la latence dans HLS, il n'est pas possible de la réduire à zéro, mais il existe des solutions sur le marché qui permettent de réduire considérablement la latence.
Découpage fin
Un autre inconvénient du moteur est l'utilisation de petits fichiers pour la transmission des données. On pourrait se demander, qu'y a-t-il de mal à cela ?
Quiconque a essayé de copier un grand nombre de petits fichiers d'un support à un autre a sûrement remarqué que la vitesse d'écriture de ce type d'ensemble est beaucoup plus lente que celle d'un fichier unique de même taille. De plus, l'intensité des accès au disque dur augmente considérablement, ce qui affecte globalement la performance de tout l'ordinateur. Par conséquent, la transmission de données vidéo sous forme de petits fragments de 10 secondes contribue également à une latence accrue du moteur.
Récapitulons brièvement tous les avantages et inconvénients de la technologie HLS.
Avantages de HLS :
- Compatibilité avec tous les appareils. Vous pouvez regarder des vidéos sur n'importe quel appareil moderne, qu'il s'agisse d'un smartphone, d'une tablette, d'un ordinateur portable ou d'un PC de bureau. L'essentiel est que le navigateur web soit à jour et compatible avec HTML5 et Media Source Extensions.
- Excellente qualité d'image. La fonction de transmission adaptative permet de modifier dynamiquement la qualité de la vidéo transmise en fonction de la bande passante de la connexion Internet, tout en cherchant à maintenir la qualité au maximum.
- Pas besoin de configurations complexes de l'équipement de l'utilisateur.
Inconvénients :
- Support limité pour le moteur sur certains appareils.
- Grosse latence dans la transmission de l'image.
- Augmentation significative des frais généraux et complexité d'optimisation en raison de l'utilisation de fichiers de petite taille. En raison des particularités du conteneur, nous ne pourrons jamais obtenir une latence inférieure à la taille du segment.
Les inconvénients de HLS ont dépassé ses avantages pour nous et nous ont poussés à chercher des alternatives.
Qu'est-ce que WebRTC
()
La plateforme WebRTC a été développée par Google en 2011 pour transmettre des données vidéo et audio en streaming entre navigateurs et applications mobiles avec une latence minimale. Pour cela, elle utilise le protocole standard UDP et des algorithmes spéciaux de gestion de flux. Aujourd'hui, c'est un projet open source, activement soutenu et développé par Google.
WebRTC est un ensemble de technologies pour la transmission vidéo et audio en peer-to-peer. Par exemple, les navigateurs des utilisateurs peuvent transmettre des données directement les uns aux autres via WebRTC, sans recourir à des serveurs distants pour stocker et traiter les données. Toutes les informations sont également traitées par les navigateurs et les applications mobiles des utilisateurs finaux.
La commodité et les grandes possibilités de cette technologie ont été pleinement appréciées par les développeurs de tous les navigateurs populaires. Aujourd'hui, le support de WebRTC est implémenté dans Mozilla Firefox, Opera, Google Chrome (et tous les navigateurs basés sur Chromium), ainsi que dans les applications mobiles sur Android et iOS.
Avec tous ses indéniables avantages, WebRTC présente toutefois quelques inconvénients majeurs.
Difficultés de choix
La technologie WebRTC est beaucoup plus complexe en termes d'interactions réseau en raison de son caractère P2P. Elle est difficile à dépanner, à tester, et peut se comporter de manière imprévisible. Par ailleurs, il est nécessaire de surmonter les NAT et les pare-feu, et d'assurer le fonctionnement dans des réseaux où le UDP est bloqué.
La mise en œuvre de WebRTC par Google est très difficile à utiliser. Il existe même une entreprise qui propose des services pour assembler les SDK. De plus, il était très difficile d'intégrer l'implémentation de Google avec notre système sans réencoder toutes les vidéos.
Cependant, nous avons longtemps souhaité offrir aux utilisateurs la possibilité de travailler avec un flux vidéo « vivant » et de minimiser le décalage de l'image à l'écran par rapport aux événements eux-mêmes. De plus, nous souhaitions rendre plus confortable l'utilisation de caméras PTZ, où les retards revêtent une importance critique.
Sachant que d'autres implémentations de lutte contre les retards ont actuellement des fonctionnalités limitées et fonctionnent de manière nettement inférieure, nous avons décidé d'utiliser WebRTC.
Ce que nous avons fait
Intégrer correctement la plateforme WebRTC est une tâche difficile. Toute erreur ou inexactitude peut entraîner une augmentation des retards dans la transmission du flux vidéo, au lieu de les réduire par rapport à d'autres plateformes.
Pour un fonctionnement correct de WebRTC, il est d'abord nécessaire de procéder à une modernisation technologique de la pile pour la vidéo web. Ce que nous avons fait.
Nous avons d'abord implémenté un serveur de protocole de signalisation WebRTC sur Websocket, ainsi qu'un serveur peer WebRTC dans le cloud basé sur SDK webrtc.org. Sa tâche consiste à distribuer des flux vidéo aux peers WebRTC clients au format H.264 + Opus/G.711 sans réencodage vidéo.
Nous avons choisi Websocket comme protocole de signalisation car il bénéficie déjà d'un bon support dans tous les navigateurs web populaires. Cela permet de réduire considérablement les coûts de développement et d'économiser du temps et des ressources en évitant les poignées de main TCP et TLS répétées par rapport à AJAX.
Le fait est qu'en l'état, WebRTC ne fournit pas de protocole de signalisation nécessaire pour configurer, maintenir et couper correctement la communication vidéo en temps réel entre les applications d'origine et les clients.
Ainsi, pour réaliser nous-mêmes la technologie de signalisation, nous avons dû développer notre propre serveur de signalisation prenant en charge plusieurs protocoles web (Websocket, WebRTC). Avec la possibilité de gérer en toute sécurité les sessions et les notifications en temps réel, la gestion de la vidéo et de nombreux autres paramètres.
Nous avons surmonté les limitations P2P en réduisant la latence non pas grâce au P2P, mais grâce à l'UDP et à la gestion du flux visant à réduire la latence. Cela est également intégré dans WebRTC, car le principal cas d'utilisation est les conversations P2P via le navigateur.
Dans le client mobile, nous avons implémenté un lecteur avec le SDK webrtc.org, car c'est le seul à gérer correctement le flux, avec tous les schémas connus de Correction d'Erreur Avant (FEC), et à disposer d'un mécanisme de retransmission des paquets correctement réalisé pour tous les navigateurs. Il est également important de noter que le SDK webrtc.org est activement développé par Google.
Quel est le résultat de l'implémentation de WebRTC ?
Pour visionner des vidéos en direct provenant des caméras, nous avons ajouté dans le cabinet personnel un nouveau lecteur optimisé basé sur WebRTC. Il assure une vitesse de chargement vidéo élevée et élimine complètement le problème de l'accumulation de retard au fur et à mesure que le temps de visionnage augmente.
Après l'intégration du support WebRTC dans le service cloud Ivideon, nous pouvons affirmer avec certitude que nos clients ont désormais accès à la diffusion de vidéos en direct de qualité complète. Actuellement, le délai de diffusion de la vidéo ne dépasse pas une seconde ! En comparaison, l'ancien moteur HLS garantissait une diffusion avec un délai de 5 à 7 secondes. La différence de rapidité de diffusion est très significative, et l'utilisateur la remarquera immédiatement après avoir commencé à utiliser notre service vidéo.
Comme nous l'avions supposé, la mise en œuvre du nouveau lecteur a permis d'améliorer la réactivité PTZ et la communication vocale avec la caméra.
Il y a juste un petit point sur lequel nous souhaitons attirer l'attention. Le nouveau lecteur WebRTC fonctionne encore en mode test. C'est pourquoi nous ne le connectons pas par défaut à tous nos clients. Mais vous pouvez l'activer vous-même en activant la fonction correspondante dans les paramètres de la caméra (pour cela, il faut se rendre dans ).
Caractéristiques de l'implémentation de WebRTC dans le service Ivideon
WebRTC est pour l'instant encore une technologie expérimentale. Son support n'est pas encore correctement implémenté dans tous les navigateurs et appareils utilisateurs, ni dans toutes les caméras.
C'est précisément cela qui explique pourquoi nous n'avons pas encore fait du lecteur WebRTC le principal par défaut pour tous les utilisateurs.
Pour le moment, nous recommandons d'utiliser WebRTC uniquement dans les navigateurs Google Chrome. Les dernières versions de Firefox et Safari prennent également en charge cette technologie, mais, malheureusement, elles restent encore instables.
Nous n'avons pas encore intégré le support de WebRTC pour les navigateurs sur appareils mobiles. Actuellement, si vous accédez depuis un appareil mobile et activez WebRTC, ce mode ne fonctionnera pas. Cependant, WebRTC est disponible dans nos applications mobiles pour et .
Pour conclure notre discussion sur les caractéristiques de l'implémentation de WebRTC dans notre service, mentionnons encore deux points délicats.
Tout d'abord, la technologie est orientée vers la diffusion de vidéos en direct en temps réel. Par conséquent, si la bande passante de votre connexion est insuffisante pour la transmission de la vidéo, vous constaterez des pertes de trames (avec HLS, vous remarquerez des freeze de la vidéo et une augmentation du délai, tandis que les trames ne tomberont pas), mais la vidéo sera tout de même diffusée en temps réel.
Deuxièmement, étant donné que la technologie est spécifiquement conçue pour travailler avec de la vidéo en direct en temps réel, nous ne l'utilisons pas pour traiter des données vidéo archivées.
Autres modifications dans le service
Actuellement, Flash n'est plus impliqué dans le mécanisme de sélection automatique du moteur. Il est encore possible d'utiliser ce type de lecteur, mais cela nécessite de le sélectionner manuellement dans les paramètres du compte ou de la caméra. Ce n'est pas une tendance, simplement, d'après les statistiques de notre service, les utilisateurs travaillant avec Flash sont presque inexistants. Et lorsque nous essayons de déterminer si le navigateur de l'utilisateur le supporte, nous perdons environ 2 secondes de temps précieux.
Voici un aperçu des changements que vous allez découvrir dans notre système de vidéosurveillance en cloud et votre espace personnel. Restez avec nous et suivez les nouvelles !
Source : habr.com
