StreamApi
C’est le besoin initial qui a donné naissance à Streamlike en 2007. Depuis, le contexte a un peu changé et les eCDNs sont apparus.
La diffusion fluide de vidéos sur les réseaux d’entreprise est un enjeu depuis bientôt 15 ans. Depuis cette époque, le nombre et le poids des vidéos consultées a explosé, que ce soit à la demande ou en direct. Streamlike a été la première technologie de diffusion en « streaming HTTP adaptatif », avant HLS et d’autres méthodes qui se sont imposées grâce à la puissance de leurs éditeurs : principalement Apple, puis Microsoft et Adobe dans une moindre mesure.
La diffusion de vidéos se fait via un réseau mondial appelé Content Delivery Network (CDN). Les personnes connectées à un réseau d’entreprise depuis un bureau ou en télétravail via un VPN se connectent au CDN en passant par le port internet de l’entreprise.
Dès 2007 Streamlike faisait du streaming (diffusion des seuls segments d’une vidéo qui sont lus, à l’opposé du téléchargement) sur le port HTTP (pas de règle particulière pour les pare-feux) en adaptatif (choix automatique parmi plusieurs flux de débits différents en fonction de la qualité de la connexion). Les bénéfices étaient déjà de ne pas saturer les réseaux internes et de s’adapter à leur état en ne diffusant que le strict nécessaire, de sécuriser les contenus en empêchant leur téléchargement et de fournir des statistiques précises sur ce qui a été consulté.
Diffusion classique en streaming adaptatif (« ABR »- Adaptative Bit Rate) . Lorsque les connexions simultanées au travers du port internet sont nombreuses, la qualité servie doit être réduite pour que la lecture puisse se poursuivre sans interruption.
Les usages ont tendance à progresser plus vite que la capacité des infrastructures. Maintenant que le Live s’est généralisé , que la qualité « standard » de vidéo en ligne est la haute définition, que les visioconférences se multiplient sous l’effet de la crise sanitaire, tout ce qui peut soulager les réseaux internes et particulièrement leur connexion à l’internet est bon à prendre.
Nous allons distinguer trois stratégies complémentaires. Les deux dernières s’apparentent à créer des CDN sur le réseau d’entreprise, d’où leur appellation « eCDN »:
- Le bridage de la qualité des vidéos lues (« Throttling »)
- La mise en place de serveurs de cache
- La diffusion interne en P2P
Le bridage de qualité de lecture
C’est ce que nous appelons le « bandwidth throttling » (littéralement, « étranglement de la bande passante »), et nous l’activons au moyen d’un paramètre appliqué au lecteur vidéo. Plutôt que de créer des encodages de basse qualité, nous réduisons dans un contexte précis le nombre de qualités disponibles. Ainsi, les mêmes vidéos pourront être vues en pleine qualité sur un site web grand public et en qualité réduite sur votre intranet.
En baissant la qualité des vidéos sur le réseau interne, on permet à plus d’utilisateurs de se connecter ensemble et on retarde le besoin de redimensionner l’accès à internet de l’entreprise.
Le bridage de qualité est aussi une mesure d’éco-conception facilement applicable à des webTVs. On réduit le volume de transfert de données pour réaliser des économies d’émissions de gaz à effet de serre et de coût de diffusion. En résolution « 720p », le volume de données est la moitié du « 1080p » ou « Full HD », alors que la qualité perçue est identique si on ne regarde pas en plein écran.
Les webTVs Streamlike proposent un mode « éco » configurable pour brider la qualité de diffusion, désactiver le démarrage automatique (autoplay) et assombrir l’interface.
Les serveurs de cache
Un serveur de cache est aussi appelé « proxy inverse » (« reverse proxy »). Plusieurs serveurs de cache sur un réseau interne constituent un « eCDN » (Enterprise Content Delivery Network).
Certaines entreprises mettent en place leurs propres proxies inverses, mais cela nécessite des ressources importantes en matière d’ingénierie logicielle et matérielle, ainsi qu’un investissement important en matériel physique.
Un proxy inverse déployé entre le CDN de Streamlike et les clients permet de mettre en cache les données selon des règles définies par l’administrateur système, pour réduire le transit de données provenant de l’internet.
On peut choisir de mettre en cache permanent l’intégralité d’un catalogue de vidéos ou seulement les vidéos les plus demandées, de manière temporaire. Dans le premier cas, toutes les demandes de vidéos seront servies depuis le cache sur le réseau interne. Dans le second, les premières demandes seront servies depuis le CDN et conservées en cache, de sorte que les suivantes seront servies depuis le réseau interne.
Les solutions logicielles les plus utilisées sont Nginx, Squid ou Varnish.
La diffusion interne en peer-to-peer (P2P)
Les solutions de diffusion en streaming Mesh / P2P ne nécessitent aucun déploiement matériel. Pour les plus simples, elles consistent à ajouter du code dans le lecteur vidéo qui fera de chaque poste de travail un point de (re)diffusion. Ce que l’un aura déjà lu sera mis à disposition d’autres clients sur le réseau interne, qui le partageront à leur tour, selon le protocole WebRTC.
La diffusion en mode P2P est performante pour des contenus consultés massivement et simultanément, c’est à dire pour des diffusions en « live » sur un réseau interne. Il n’y a alors pratiquement plus de transit internet et la qualité servie peut être meilleure car elle n’est pas conditionnée par la bande-passante du raccordement du réseau à l’internet. En revanche, la diffusion d’un Live se trouve retardée d’une trentaine de secondes par rapport à une lecture directe sur internet.
Pour la VOD et des contenus qui ne sont consultés qu’occasionnellement, il n’y a pratiquement aucun avantage à diffuser en P2P.
Les principaux éditeurs (Lumen/Streamroot, Peer5, Kollective, Hivestreaming et Strivecast) proposent des solutions pour un ou plusieurs lecteurs utilisés par Streamlike (Theoplayer, Videojs et Flowplayer). Certains proposent également des SDK (Software Development Kit – kit de développement logiciel) pour Android et iOS. Les différences portent aussi sur le niveau de sécurité et les statistiques mises à disposition. En général, il est possible de tester l’efficacité d’une diffusion P2P sur des postes connectés à un même réseau interne, au travers d’un mode de « test silencieux ».
Il est donc très simple de combiner une diffusion publique via le CDN de Streamlike avec une diffusion interne en mode P2P, quel que soit l’éditeur que vous aurez choisi. Vous pourrez même décider quelles vidéos, quelles playlists, quelles webTVs seront diffusées en P2P et lesquelles seront diffusées de manière classique par le CDN de Streamlike.
Le prix des solutions P2P est très variable selon les éditeurs. En général, les tarifs sont basés sur le nombre total de collaborateurs dans l’entreprise et sur l’usage. L’intérêt économique se juge alors sur la taille des publics internes que l’on veut toucher en direct, sur la fréquence de cet usage et sur la bande-passante internet disponible.
Notons que certains éditeurs proposent des formules « par événement » qui seront plus avantageuses si le besoin est occasionnel ou exceptionnel.
Que choisir ?
Tout dépend du besoin. Nous voyons deux cas favorables à un eCDN : la mise en cache intégrale de votre médiathèque sur un ou plusieurs serveurs et la diffusion fréquente de directs (ou StreamOuts) destinés à un grand nombre de vos collaborateurs.
Pour des opérations exceptionnelles, l’activation d’un streaming P2P « par événement » est à la fois efficace et économique.
Voici comment nous pourrions comparer les différentes solutions :
« ABR / CDN » = « Adaptative Bit Rate et CDN »
Avec un eCDN, vos transferts de données internes génèrent toujours des Gaz à Effet de Serre (GES), mais moins d’équipements électriques sont sollicités (pas de serveurs dans le cas du P2P) que pour une diffusion classique. L’avantage est donc au eCDN en matière d’impact environnemental, au moins dans les cas où il est le plus efficace.
[English] : How to efficiently stream videos on an internal network?
