You are currently viewing Histoire et évolutions du célèbre lecteur polyvalent VLC
L’équipe de VideoLAN. © VLC

Histoire et évolutions du célèbre lecteur polyvalent VLC

 

Le cône de chantier est l’emblème de VLC © VLC

L’acronyme VLC est à l’origine celui du client d’une solution réseau complète prévue pour diffuser et lire de la vidéo en streaming transportée par la fibre optique du campus. Diminutif de VideoLAN Client, c’est aujourd’hui le lecteur vidéo le plus polyvalent. Il fait partie de la boîte à outils de tout professionnel de l’audiovisuel, et plus largement de toute personne voulant lire un fichier vidéo quel qu’il soit, sur n’importe quelle plate-forme : MacOS, iOS, Linux, Windows, Android, Unix, Chrome OS, OS/2, Solaris, etc.

Les raisons qui rendent l’aventure de la naissance et de l’évolution de VLC passionnante sont multiples. C’est une des applications les plus téléchargées au monde, née sur les bancs d’une école française. C’est aussi un des plus grands succès de l’écosystème du logiciel libre, derrière lequel se développe une véritable philosophie.

 

Jean-Baptiste Kempf à l’événement Tech Challenger 2023. © VLC

 

La destinée de VLC est aujourd’hui encadrée par une association à but non lucratif, VideoLAN, dirigée par une personnalité atypique et attachante, Jean-Baptiste Kempf. Il est revenu avec nous sur l’histoire de ce lecteur symbolisé par la célèbre icône orange et blanche en forme de cône de signalisation. Il nous présente également les dernières recherches de ses équipes.

 

Image d’archive de l’association VideoLAN. © VLC

Peux-tu nous présenter les étapes clés et l’origine de VLC ?

VLC est un des logiciels du projet étudiant VideoLAN de l’École centrale Paris débuté en 1994. Le but était la diffusion par fibre optique de flux vidéo satellite sur un réseau IP. Les ordinateurs étant alors des 486DX66 et des Pentium 90, des cartes d’accélération étaient nécessaires pour décoder la vidéo. À cette époque, la technologie satellite suscitait un grand engouement dans le domaine de l’audiovisuel. Le projet originel nommé Network 2 000 permettait d’éviter l’achat sur le campus de l’École centrale Paris de 1 500 décodeurs satellite et autant d’antennes. Il aurait pu s’arrêter après une démo en 1997.

 

Ancienne interface de VLC © VLC

Toute la solution de streaming était déployée, avec le serveur et un ensemble d’éléments dont un client de lecture vidéo déployés sur un nouveau réseau. Mais en septembre 1998, de nouveaux étudiants de deuxième année ont décidé de reprendre le projet pour le faire évoluer vers une solution de streaming vidéo sur un réseau local. Dès le début, la volonté de convertir le projet vers un modèle open source était clairement affirmée. Nous souhaitions lire de la vidéo en direct sur un LAN (Local Area Network), d’où très basiquement le nom VideoLAN. Le projet était vaste et comportait de nombreux logiciels, notamment un client et un serveur. Le client deviendra VideoLAN client, puis VLC.

À l’origine, personne n’avait donc pour but de créer VLC. VLC savait décoder les flux satellites, a été complété avec le support des fichiers vidéo puis celui des DVD. À partir de 1998, le projet de développement était animé par une équipe de quatre à cinq étudiants chaque année. En février 2001, l’école a autorisé le passage en open source de tous les logiciels de VideoLAN, y compris le client. À partir de ce moment, des gens externes ont commencé à contribuer au projet et notamment au portage sur Windows et MacOS.

 

Ancienne interface de VLC sur MacOS. © VLC

 

Sur quel système était initialement développé VLC et le reste de la solution ?

Véritable logiciel de « geek », les différentes briques de la solution VideoLAN étaient développées avec Linux et BeOS. Grâce à l’ouverture en open source, de plus en plus de gens ont contribué au développement du lecteur permettant une impressionnante et rapide évolution de la quantité de formats supportée. Comme sous Linux les logiciels sont proposés sous forme de package ; les codecs sont depuis l’origine inclus nativement au logiciel. Même après le portage sous Windows et Mac OS, cet important concept rendant le lecteur indépendant a été conservé. C’est ce qui rend VLC vraiment cool : il n’est pas nécessaire de manipuler des listes de codec. Soit une vidéo est lisible dans VLC parce que le codec y est intégré, soit cela ne fonctionne pas. L’installation de n’importe quel package de codecs n’y changera rien. Initialement VLC était également intéressant parce qu’il permettait la lecture de DVD sans devoir payer de lecteur tel que PowerDVD, et cela même sous MacOS X qui à son lancement, et avant l’arrivée d’iDVD, n’était pas équipé de lecteur DVD.

 

Jean Baptiste Kempf, professeur d’un jour aux VideoLAN Dev Days 2019 © VLC

À quel moment as-tu rejoint le développement de VLC ? Et à quel moment le projet est-il sorti des murs de l’École centrale ?

Je suis rentré à l’École centrale Paris en 2003 et cette même année, j’ai rejoint l’association informatique VideoLAN. Peu à peu, le projet a connu une période de stagnation ; les étudiants étaient moins impliqués. Ce qui restait à développer était vraiment difficile et en même temps moins rigolo : opérations de maintenance et ajout de codecs. Au début du mois de janvier 2007, deux ou trois personnes seulement restaient actives sur le projet. Je suis parti un an en volontariat international au consulat de France à Washington et, à mon retour, j’ai créé l’association loi 1901 VideoLAN.

À ce moment-là, en 2008, VLC est sorti du giron de l’école, non sans difficultés car certains anciens étudiants qui avaient travaillé sur le projet entre 2001 et 2004 souhaitaient conserver le projet en interne. Mais une réforme de la scolarité laissait beaucoup moins de temps aux élèves pour ce type de projet. Le logiciel devenant parallèlement de plus en plus complexe à maintenir, ce n’était pas tenable.

 

 

Compteur de téléchargement VLC au CES 2018. © VLC

Vous souhaitiez alors aller plus loin avec VLC ?

Nous avons d’abord récupéré un peu de fonds. Pas beaucoup, mais suffisamment pour acquérir des ordinateurs et des serveurs, récupérer les noms de domaine et motiver les anciens élèves à rejoindre l’aventure.

 

 

Aviez-vous imaginé un modèle économique en dehors de l’association ?

L’association a toujours fonctionné sans générer d’argent. Au début, nous proposions des prestations et des services autour de la solution, facturés en tant qu’indépendants. En 2012, j’ai créé VideoLabs, une entreprise de service et d’intégration autour des solutions open source ; 98 % de notre chiffre d’affaires étant réalisé autour de VLC. VideoLabs est le pendant commercial de l’association VideoLAN, mais si l’entreprise meurt elle n’impacte pas VLC. Sa création coïncide avec le virage du streaming sur smartphones, alors qu’il devenait de plus en plus difficile de développer sur des plates-formes et des environnements différents et propriétaires. Il faut par exemple obtenir les approbations d’Apple pour iOS.

 

Quels services proposez-vous et quels sont vos clients ?

L’offre et les clients sont très variés. De nombreuses sociétés intègrent le moteur VLC dans leurs applications et beaucoup d’app jouent de la vidéo grâce à la flexibilité de ce lecteur. Certaines personnes nous ont mandatés pour améliorer des fonctionnalités de la version officielle de VLC. La plupart des développeurs core de VLC travaillent pour VideoLabs. Il n’y a pas d’investisseurs.

 

Image d’archive de Jean Baptiste Kempf et de l’association VideoLAN © VLC

Ces améliorations développées pour vos clients aboutissent-elles à des versions personnalisées du lecteur ?

Une seule version de VLC existe ; les améliorations y sont toujours intégrées.

 

Parmi vos clients, y a-t-il des acteurs du milieu du broadcast, de la télévision ?

Oui, notamment France 2, RTBF, Netflix, NBC. Certains nous ont consulté parce que des fichiers MXF OP1A ne fonctionnaient pas bien sur VLC qui est leur outil de QA (Quality Assurance, ou vérification). D’autres nous ont demandé si nous pouvions améliorer des problèmes de latence en streaming. Des fournisseurs d’accès nous ont sollicité pour savoir si nous pouvions autoriser leur app à lire des flux TV. Nous avons collaboré à de beaux projets pour la XBox, sur des applications avec des flux multicasts, qui permettaient même la lecture de flux H-264 entrelacés. La VR a également été propice à des développements passionnants, et notamment une version spéciale VLC. Le lecteur VLC est principalement utilisé parce qu’il lit vraiment tous les formats sur toutes les plates-formes. Des fournisseurs de contenu tels que Netflix peuvent générer plusieurs encodages de leurs programmes en fonction des plates-formes. Pour certains de nos clients, il est plus simple lorsqu’ils possèdent déjà leur infrastructure IPTV d’utiliser VLC en direct pour éviter plusieurs encodages.

 

Développeurs attentifs lors des VideoLAN Dev Days 2019. © VLC

 

Combien de personnes travaillent chez VideoLabs ?

Au commencement en 2013 nous étions quatre, aujourd’hui nous sommes vingt-quatre. Parmi nos sujets actuels, il y a la low latency (faible latence), la 3D et l’algorithme de compression AV1. Les compétences de nos équipes sont duales : informatiques et audiovisuelles. Aucune formation ne proposant ce type de profil, nous formons nos collaborateurs. Même parmi les professionnels de la vidéo, peu de personnes disposent de la finesse de compréhension du signal vidéo, et de la compression, les connaissances à maîtriser sont très complexes et la quantité d’informations à assimiler très grande.

 

Des évolutions de la vidéo sont actuellement en cours dans de nombreux domaines : l’espace colorimétrique avec le wide gamut, la dynamique avec le HDR et même la cadence des images avec le HFR. Êtes-vous proactifs sur ces développements ?

Le sujet est intéressant et correspond à un important travail en cours sur VLC. VLC est reconnu pour tout lire et initialement cela voulait dire tous les formats vidéo. Aujourd’hui ce n’est plus tous les formats vidéo, mais tous les formats de sortie, et c’est très complexe. Par exemple, le terme HDR ne veut rien dire. Lorsqu’on commence « à gratter » il regroupe de nombreux formats. Dolby Vision propose déjà huit profils avec des fonctions de transfert différentes. On peut également citer Dolby Atmos, un autre terme marketing dont le sens n’est pas évident.

 

Interface de VLC sur iOS 2.6.0. © VLC

Derrière le terme Dolby Atmos, il y a le concept de mixage objet…

Oui, mais si on prend cet exemple, on retrouve le Dolby Atmos sur des disques Blu-ray alors que le son y est en 7.1. Cela veut-il dire qu’il y a eu un pré-mixage objet et qu’on exploite quelques métadonnées pour le repasser en 7.1 ? Il est assez compliqué de démêler le marketing de la technique. Deux gros sujets sont le HDR et la « next génération » audio, parmi lesquels on trouve l’ambisonic que l’on supporte dans la version 3.0 et le mixage objet. Le HDR sur « desktop » est notamment un enfer. Dès que nous sortons des environnements très contrôlés comme les téléphones avec du hardware propriétaire ou les Apple TV, Windows et Mac OS notamment, ne sont pas contrôlés et c’est infernal.

 

Quels sont les futurs projets et les évolutions importantes de VLC ?

Actuellement nous menons un travail qui n’est pas du tout rigolo ; c’est la refonte du corps de synchronisation de VLC pour être véritablement « frame accurate » (précis à la frame ou à l’image). Une des différences de VLC par rapport à un lecteur professionnel, c’est qu’il n’a jamais affiché les timestamps SMPTE, les timecodes et les dropcodes. Ce n’était jusqu’à présent pas vraiment un besoin. VLC ayant été conçu en tant que lecteur de streaming, la synchronisation de la lecture de l’audio par rapport au déroulement du temps est responsable d’une limite du lecteur. Lorsque ce dernier s’aperçoit qu’il est en retard par rapport au temps réel, dans le mode par défaut de VLC l’audio est resamplé, une technique à l’origine de nombreuses modifications de pitch. Des spécialistes de l’audio dénoncent les problèmes audio de VLC : ils ont raison. Tout le travail sur la clock (l’horloge) est absolument invisible pour les humains normaux, mais pour les professionnels, c’est un vrai sujet.

 

Vous souhaitez donc plus cibler le marché professionnel ?

Oui ! Nous souhaitons être plus exacts et répondre à des besoins pros pour lesquels les limites de VLC étaient bloquants.

 

Interface de VLC en lecteur DVD avec Blade Runner 2049. © VLC

 

Vous développez actuellement VLC.js. Peux-tu nous présenter ce nouveau déploiement ?

VLC est porté sur de très nombreuses plates-formes, mais une de celle qui manquait est le Web. Le projet VLC.js consiste à coder les millions de lignes CS et C++ de VLC pour les faire tourner dans le navigateur. L’intérêt que je présente en démo c’est de pouvoir lire du MKV, du HEVC, du HDV, du VP9 sous Mac ou des formats professionnels comme le MXF ou le DNxHD directement dans le navigateur. Cela permet d’éviter de reporter tout le processus de décodage au niveau du serveur. Aujourd’hui cela a du sens de ré-encoder lorsqu’il y a des millions de vues, même si cela demande déjà des infrastructures « délirantes » et si cela engendre une perte sensible de qualité (par exemple lorsqu’un signal vidéo en 4:2:2 est encodé en H-264 3 Mbits/sec en 4:2:0). Nous apportons le support de tous les formats bizarres de VLC directement dans le navigateur, pour lire des archives ou des fichiers pros par exemple.

 

Y a-t-il des acteurs majeurs, des fabricants présents sur le marché du broadcast qui vous sollicitent ?

Oui, mais je ne peux pas donner de noms. Il y a plus d’argent dans le monde du broadcast sur les serveurs et les encodeurs que sur les players. Même si des players comme ceux de Panasonic proposent du frame by frame, ils font partie de solutions complètes. Lorsqu’il y a des encodeurs basses latence, on nous mandate pour permettre à VLC d’être capable de lire leurs flux, cela permet aux fabricants de vendre leurs solutions.

 

Avez-vous d’autres projets ?

En plus du travail sur la qualité et la professionnalisation, nous abordons un travail à plus long terme d’indexation pour proposer l’intégration de contenu, de chaînes de radio ou de TV et offrir ainsi une alternative au monopole et à l’omniprésence des plates-formes américaines. Cela serait matérialisé par une sorte d’outil de media asset management des flux en local.

 

Menez-vous des réflexions et des recherches par rapport à l’impact écologique du streaming ?

Oui, mais je pose souvent la question de ce qui consomme le plus dans la lecture d’un flux de streaming ? 80 % de la consommation vient en fait du rétroéclairage des écrans qui affichent la vidéo. Le décodage effectué sur VLC 3.0 avec l’exploitation de l’accélération GPU sur un matériel optimisé consomme 3 à 4 watts, là où l’écran va consommer 100 watts. Réduire la consommation en bande passante des encodeurs modernes permet un gain réel de consommation réseau et la nécessité d’un moins grand nombre de serveurs à qualité constante.

 

As-tu constaté des évolutions dans les derniers codecs vidéo ?

Les formats évoluent tout le temps. Nous pensions à un moment que le H-264 ferait consensus et deviendrait un standard commun, mais c’est loin d’être le cas. De très nombreux nouveaux codecs sont apparus tels que HEVC, VP9, AV1, MPEG5 Essential Video Coding (EVC), LCEVC (Low Complexity Enhancement Video Coding), de nombreux formats de HDR, quatre formats de Next Generation Audio (NGA) sans évoquer les protocoles de streaming tels que le DASH (Dynamic Adaptive Streaming over HTTP) ou le HLS. Mais dans le fond, les véritables bouleversements sont limités : AV1 est une évolution de VP9, et EVC une évolution de H-265. Le seul changement véritablement intéressant à venir c’est la vidéo volumétrique mais l’échéance applicative est lointaine (cinq ans au minimum).

 

Menez-vous des recherches à plus long terme ?

Nous travaillons sur le temps réel. Comparativement aux techniques basse latence développées pour optimiser VLC, le procédé est totalement différent. Il consiste à produire, streamer et décoder les images le plus rapidement possible. Sur VLC ou FFmpeg (un autre projet célèbre open source auquel je collabore), les images sont mises en mémoire tampon (« bufferisées ») avant d’être synchronisées à l’étape finale.

 

Extrait de l’article paru pour la première fois dans Mediakwest #52, pp. 112-116