il est tr\u00e8s pratique et efficace d'organiser des diffusions \u00e0 un large public gr\u00e2ce \u00e0 la possibilit\u00e9 de charger des segments une seule fois sur le CDN.<\/li>\n<\/ul>\n\nMalgr\u00e9 la simplicit\u00e9 du moteur, tout ne se passe pas aussi bien qu'il y para\u00eet. Le principal probl\u00e8me est que les d\u00e9veloppeurs de lecteurs tiers se sont \u00e9cart\u00e9s des recommandations d'Apple, par exemple en ce qui concerne les formats audio pris en charge. En particulier, de nombreux d\u00e9veloppeurs ont commenc\u00e9 \u00e0 ajouter la possibilit\u00e9 de travailler avec des flux audio populaires : vid\u00e9o mpeg2, audio mpeg2, etc. En cons\u00e9quence, il a fallu cr\u00e9er diff\u00e9rents formats de playlist pour diff\u00e9rents lecteurs.<\/p>\n
Mais l'un des plus grands probl\u00e8mes du moteur HLS est le temps de latence \u00e9lev\u00e9 dans la transmission des donn\u00e9es.<\/p>\n
L'origine des \"ralentissements\"<\/h2>\n \nLa principale raison de la haute latence de HLS r\u00e9side dans le fait que les programmeurs ont cr\u00e9\u00e9 le moteur pour obtenir une qualit\u00e9 d'image maximale. Par cons\u00e9quent, les param\u00e8tres de l'intervalle d'images utilis\u00e9 et le volume du tampon de lecture ne conviennent tout simplement pas \u00e0 la diffusion de vid\u00e9os en direct. En cons\u00e9quence, il y a une latence assez \u00e9lev\u00e9e dans la transmission de la vid\u00e9o, qui peut atteindre 5 \u00e0 7 secondes.<\/p>\n
D'une part, cela semble peu, par exemple pour ceux qui regardent un film depuis un serveur de vid\u00e9o. Mais pour les syst\u00e8mes de vid\u00e9osurveillance, la latence dans la transmission de la vid\u00e9o peut avoir une grande importance.<\/p>\n
Si vous surveillez un bureau o\u00f9 les employ\u00e9s se d\u00e9tachent de l'\u00e9cran une fois par heure, alors une latence de 5 secondes n'a aucune importance. Mais les gens ont commenc\u00e9 \u00e0 se plaindre, par exemple, lors de la diffusion d'un match de football, que dans le chat, quelqu'un a d\u00e9j\u00e0 \u00e9crit GOOOOL, mais la vid\u00e9o ne le montre pas encore :). Nous avons d\u00e9j\u00e0 plusieurs cas d'utilisation o\u00f9 Ivideon doit pratiquement remplacer Skype.<\/p>\n
Peut-on surmonter la latence dans HLS? La r\u00e9ponse \u00e0 cette question ressemble \u00e0 un discours d'un exterminateur de rats chevronn\u00e9 lors d'une conf\u00e9rence pour des d\u00e9ratiseurs d\u00e9butants : \u00ab On ne peut pas exterminer les rats, mais on peut r\u00e9duire leur population \u00e0 un minimum raisonnable \u00bb. Ainsi, concernant la latence dans HLS, il n'est pas possible de la r\u00e9duire \u00e0 z\u00e9ro, mais il existe des solutions sur le march\u00e9 qui permettent de r\u00e9duire consid\u00e9rablement la latence.<\/p>\n
D\u00e9coupage fin<\/h2>\n \nUn autre inconv\u00e9nient du moteur est l'utilisation de petits fichiers pour la transmission des donn\u00e9es. On pourrait se demander, qu'y a-t-il de mal \u00e0 cela ?<\/p>\n
Quiconque a essay\u00e9 de copier un grand nombre de petits fichiers d'un support \u00e0 un autre a s\u00fbrement remarqu\u00e9 que la vitesse d'\u00e9criture de ce type d'ensemble est beaucoup plus lente que celle d'un fichier unique de m\u00eame taille. De plus, l'intensit\u00e9 des acc\u00e8s au disque dur augmente consid\u00e9rablement, ce qui affecte globalement la performance de tout l'ordinateur. Par cons\u00e9quent, la transmission de donn\u00e9es vid\u00e9o sous forme de petits fragments de 10 secondes contribue \u00e9galement \u00e0 une latence accrue du moteur.<\/p>\n
R\u00e9capitulons bri\u00e8vement tous les avantages et inconv\u00e9nients de la technologie HLS.<\/p>\n
Avantages de HLS :<\/b><\/p>\n\nCompatibilit\u00e9 avec tous les appareils. Vous pouvez regarder des vid\u00e9os 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 \u00e0 jour et compatible avec HTML5 et Media Source Extensions.<\/li>\n Excellente qualit\u00e9 d'image. La fonction de transmission adaptative permet de modifier dynamiquement la qualit\u00e9 de la vid\u00e9o transmise en fonction de la bande passante de la connexion Internet, tout en cherchant \u00e0 maintenir la qualit\u00e9 au maximum.<\/li>\n Pas besoin de configurations complexes de l'\u00e9quipement de l'utilisateur.<\/li>\n<\/ol>\n\nInconv\u00e9nients :<\/b><\/p>\n\nSupport limit\u00e9 pour le moteur sur certains appareils.<\/li>\n Grosse latence dans la transmission de l'image.<\/li>\n Augmentation significative des frais g\u00e9n\u00e9raux et complexit\u00e9 d'optimisation en raison de l'utilisation de fichiers de petite taille. En raison des particularit\u00e9s du conteneur, nous ne pourrons jamais obtenir une latence inf\u00e9rieure \u00e0 la taille du segment.<\/li>\n<\/ol>\n\nLes inconv\u00e9nients de HLS ont d\u00e9pass\u00e9 ses avantages pour nous et nous ont pouss\u00e9s \u00e0 chercher des alternatives.<\/p>\n
Qu'est-ce que WebRTC<\/h2>\n \nc<\/noindex>)<\/p>\nLa plateforme WebRTC a \u00e9t\u00e9 d\u00e9velopp\u00e9e par Google en 2011 pour transmettre des donn\u00e9es vid\u00e9o 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\u00e9ciaux de gestion de flux. Aujourd'hui, c'est un projet open source, activement soutenu et d\u00e9velopp\u00e9 par Google.<\/p>\n
WebRTC est un ensemble de technologies pour la transmission vid\u00e9o et audio en peer-to-peer. Par exemple, les navigateurs des utilisateurs peuvent transmettre des donn\u00e9es directement les uns aux autres via WebRTC, sans recourir \u00e0 des serveurs distants pour stocker et traiter les donn\u00e9es. Toutes les informations sont \u00e9galement trait\u00e9es par les navigateurs et les applications mobiles des utilisateurs finaux.<\/p>\n
La commodit\u00e9 et les grandes possibilit\u00e9s de cette technologie ont \u00e9t\u00e9 pleinement appr\u00e9ci\u00e9es par les d\u00e9veloppeurs de tous les navigateurs populaires. Aujourd'hui, le support de WebRTC est impl\u00e9ment\u00e9 dans Mozilla Firefox, Opera, Google Chrome (et tous les navigateurs bas\u00e9s sur Chromium), ainsi que dans les applications mobiles sur Android et iOS.<\/p>\n
Avec tous ses ind\u00e9niables avantages, WebRTC pr\u00e9sente toutefois quelques inconv\u00e9nients majeurs. <\/p>\n
Difficult\u00e9s de choix<\/h2>\n \nLa technologie WebRTC est beaucoup plus complexe en termes d'interactions r\u00e9seau en raison de son caract\u00e8re P2P. Elle est difficile \u00e0 d\u00e9panner, \u00e0 tester, et peut se comporter de mani\u00e8re impr\u00e9visible. Par ailleurs, il est n\u00e9cessaire de surmonter les NAT et les pare-feu, et d'assurer le fonctionnement dans des r\u00e9seaux o\u00f9 le UDP est bloqu\u00e9.<\/p>\n
La mise en \u0153uvre de WebRTC par Google est tr\u00e8s difficile \u00e0 utiliser. Il existe m\u00eame une entreprise qui propose des services pour assembler les SDK. De plus, il \u00e9tait tr\u00e8s difficile d'int\u00e9grer l'impl\u00e9mentation de Google avec notre syst\u00e8me sans r\u00e9encoder toutes les vid\u00e9os.<\/p>\n
Cependant, nous avons longtemps souhait\u00e9 offrir aux utilisateurs la possibilit\u00e9 de travailler avec un flux vid\u00e9o \u00ab vivant \u00bb et de minimiser le d\u00e9calage de l'image \u00e0 l'\u00e9cran par rapport aux \u00e9v\u00e9nements eux-m\u00eames. De plus, nous souhaitions rendre plus confortable l'utilisation de cam\u00e9ras PTZ, o\u00f9 les retards rev\u00eatent une importance critique.<\/p>\n
Sachant que d'autres impl\u00e9mentations de lutte contre les retards ont actuellement des fonctionnalit\u00e9s limit\u00e9es et fonctionnent de mani\u00e8re nettement inf\u00e9rieure, nous avons d\u00e9cid\u00e9 d'utiliser WebRTC. <\/p>\n
Ce que nous avons fait<\/h2>\n \n
Pour un fonctionnement correct de WebRTC, il est d'abord n\u00e9cessaire de proc\u00e9der \u00e0 une modernisation technologique de la pile pour la vid\u00e9o web. Ce que nous avons fait.<\/p>\n
Nous avons d'abord impl\u00e9ment\u00e9 un serveur de protocole de signalisation WebRTC sur Websocket, ainsi qu'un serveur peer WebRTC dans le cloud bas\u00e9 sur SDK webrtc.org. Sa t\u00e2che consiste \u00e0 distribuer des flux vid\u00e9o aux peers WebRTC clients au format H.264 + Opus\/G.711 sans r\u00e9encodage vid\u00e9o.<\/p>\n
Nous avons choisi Websocket comme protocole de signalisation car il b\u00e9n\u00e9ficie d\u00e9j\u00e0 d'un bon support dans tous les navigateurs web populaires. Cela permet de r\u00e9duire consid\u00e9rablement les co\u00fbts de d\u00e9veloppement et d'\u00e9conomiser du temps et des ressources en \u00e9vitant les poign\u00e9es de main TCP et TLS r\u00e9p\u00e9t\u00e9es par rapport \u00e0 AJAX.<\/p>\n
Le fait est qu'en l'\u00e9tat, WebRTC ne fournit pas de protocole de signalisation n\u00e9cessaire pour configurer, maintenir et couper correctement la communication vid\u00e9o en temps r\u00e9el entre les applications d'origine et les clients.<\/p>\n
Ainsi, pour r\u00e9aliser nous-m\u00eames la technologie de signalisation, nous avons d\u00fb d\u00e9velopper notre propre serveur de signalisation prenant en charge plusieurs protocoles web (Websocket, WebRTC). Avec la possibilit\u00e9 de g\u00e9rer en toute s\u00e9curit\u00e9 les sessions et les notifications en temps r\u00e9el, la gestion de la vid\u00e9o et de nombreux autres param\u00e8tres.<\/p>\n
Nous avons surmont\u00e9 les limitations P2P en r\u00e9duisant la latence non pas gr\u00e2ce au P2P, mais gr\u00e2ce \u00e0 l'UDP et \u00e0 la gestion du flux visant \u00e0 r\u00e9duire la latence. Cela est \u00e9galement int\u00e9gr\u00e9 dans WebRTC, car le principal cas d'utilisation est les conversations P2P via le navigateur.<\/p>\n
Dans le client mobile, nous avons impl\u00e9ment\u00e9 un lecteur avec le SDK webrtc.org, car c'est le seul \u00e0 g\u00e9rer correctement le flux, avec tous les sch\u00e9mas connus de Correction d'Erreur Avant (FEC), et \u00e0 disposer d'un m\u00e9canisme de retransmission des paquets correctement r\u00e9alis\u00e9 pour tous les navigateurs. Il est \u00e9galement important de noter que le SDK webrtc.org est activement d\u00e9velopp\u00e9 par Google.<\/p>\n
Quel est le r\u00e9sultat de l'impl\u00e9mentation de WebRTC ?<\/h2>\n \n
![\"WebRTC](\"\/wp-content\/uploads\/2019\/04\/d185b546f5fc4c15021481c0cc2fedbd.jpeg\")