yt-dlp : un runtime JavaScript externe est désormais indispensable pour une prise en charge complète de YouTube

• yt-dlp est un outil de téléchargement en ligne de commande permettant de télécharger de l’audio et de la vidéo depuis des milliers de sites, et constitue un fork de youtube-dl
• Pour le déchiffrement de n/sig de YouTube, un runtime JavaScript externe (par ex. Deno, Node.js, Bun, QuickJS) est désormais requis avec le nouveau module yt-dlp-ejs
• Deno est défini comme runtime par défaut, et les utilisateurs peuvent en choisir un autre avec l’option --js-runtimes
• Avec ce changement, l’installation de yt-dlp-ejs et d’un runtime JS devient indispensable pour utiliser pleinement les fonctionnalités liées à YouTube
• L’ajout d’une dépendance à un runtime externe constitue une mesure nécessaire pour répondre aux évolutions de la structure de chiffrement de YouTube, et devient un élément clé de la maintenance future

---

Présentation de yt-dlp

• yt-dlp est un fork de youtube-dl, développé à partir de youtube-dlc, qui n’est plus maintenu
• Il permet de télécharger de l’audio et de la vidéo depuis des milliers de sites web, et prend en charge diverses fonctionnalités de sélection de formats, post-traitement, sous-titres et plugins

Changements liés à la prise en charge de YouTube

• Le paquet yt-dlp-ejs est nécessaire pour le déchiffrement des valeurs n/sig de YouTube
  • Ce paquet est distribué sous Unlicense et inclut des composants sous licences MIT et ISC
• L’exécution de yt-dlp-ejs nécessite un runtime JavaScript
  • Runtimes pris en charge : deno (recommandé), node.js, bun, QuickJS
  • Le paramétrage correspondant peut être défini avec l’option --js-runtimes
• L’option --no-js-runtimes permet de réinitialiser la configuration du runtime par défaut

Installation et dépendances

• yt-dlp prend en charge Python 3.10+ (CPython) et 3.11+ (PyPy)
• Dépendances fortement recommandées :
  • ffmpeg / ffprobe : pour la fusion audio/vidéo et le post-traitement
  • yt-dlp-ejs : pour le déchiffrement de YouTube
  • runtime JavaScript : pour exécuter yt-dlp-ejs
• Parmi les dépendances réseau optionnelles figurent certifi, brotli, requests, curl_cffi, etc.

Principales options de commande

• --js-runtimes RUNTIME[:PATH] : définir le runtime JS à utiliser
• --no-js-runtimes : désactiver tous les runtimes JS
• --remote-components COMPONENT : option permettant d’autoriser des composants JS externes
• --no-remote-components : bloquer le chargement de composants distants

Importance

• Avec ce changement, yt-dlp exige désormais un runtime JS externe pour assurer une prise en charge complète de la structure de chiffrement la plus récente de YouTube
• Il s’agit d’un changement structurel destiné à répondre aux mises à jour continues de sécurité et de chiffrement de YouTube, et d’une évolution clé pour la maintenance future et l’extension des fonctionnalités

[kimjoin2]

Waouh... C’est impressionnant de voir à quel point ils bloquent les choses, et tout aussi impressionnant de voir comment d’autres arrivent à contourner ça. Je me demande comment ils analysent tout ça et parviennent à le faire.

[GN⁺]

Avis Hacker News

• Déjà inclus dans les dépôts Arch, donc ça fonctionne immédiatement
  Il suffit d’ajouter un flag à la commande yt-dlp --cookies-from-browser firefox --remote-components ejs:github ...
  À l’exécution, le solver est téléchargé à la volée, et ça ne prend qu’environ 0,5 seconde. J’ai l’impression que le démarrage du téléchargement est nettement plus rapide
  Cela dit, dans des environnements restreints, ce serait bien de pouvoir récupérer le solver à l’avance avec une commande séparée. C’est déjà satisfaisant, mais une automatisation du packaging rendrait ça encore plus pratique

  • Ravi d’entendre que c’est plus rapide. Ces temps-ci, même YouTube fonctionne mal dans les navigateurs, donc c’est impressionnant qu’une équipe arrive à maintenir l’accès via un script Python
  • Je me demande dans quel environnement Python fonctionne mais pas JS
    Si le problème est la sécurité, avec Deno le sandboxing est bien géré
    Si l’OS ne prend pas en charge Deno ou Node, on peut aussi envisager QuickJS, écrit en C. C’est plus lent, mais ça fonctionne presque partout
    En revanche, dans ce cas, le sandboxing disparaît. Cela dit, si le code vient du domaine officiel de YouTube, je pense qu’on peut lui faire confiance
  • Si vous voulez récupérer le solver à l’avance, il suffit de télécharger n’importe quelle vidéo une fois, puis de copier le fichier ejs depuis le répertoire de cache de yt-dlp, par exemple /home/username/.cache
    Ou alors vous pouvez tenter une automatisation du packaging avec make yt-dlp-extra
  • Le paquet AUR yt-dlp-ejs semble justement correspondre à cet usage
  • J’ai installé Deno manuellement via Chocolately, et yt-dlp aussi via choco, en version v2025.10.22

• Récemment, YouTube a commencé à imposer l’en-tête referrer pour les vidéos intégrées
  Si on accède directement à youtube.com/embed/<videoid>, une erreur s’affiche, et la FAQ précise que c’est une politique intentionnelle
  D’après la documentation officielle, l’intégrateur doit fournir un HTTP Referer, sinon l’écran affiche « error 153 »

  • De plus en plus de services d’intégration évoluent dans ce sens. Le but est de renforcer le tracking. Parfois, ils vont même jusqu’à exiger une connexion
  • En réalité, on peut contourner ça avec une simple ligne de JS de redirection. Le coût d’implémentation se chiffre en centaines de milliers de dollars, et le coût du contournement est nul. Au fond, ça ressemble surtout à un message du type : « si on le veut, on peut vous bloquer autant qu’on veut »

• Quand QuickTime est sorti en 1991, je pensais qu’il allait de soi qu’on pouvait copier, coller et enregistrer une vidéo
  Aujourd’hui, j’ai du mal à croire que même des vidéos sans DRM offrent une expérience utilisateur aussi mauvaise

  • C’est quand même bien mieux aujourd’hui qu’avant. À l’époque, installer RealPlayer, Flash, des packs de codecs, etc., finissait souvent par ruiner le système avec de l’adware.
    Maintenant, le lecteur par défaut de l’OS ou VLC suffit dans la plupart des cas
  • Le début des années 90 était la période la plus passionnante du PC. Aujourd’hui, avec les smartphones devenus dominants, pour l’utilisateur moyen la notion de copier/enregistrer ne survit plus guère qu’à travers les captures d’écran ou l’enregistrement d’écran
  • La vidéo a une densité de données élevée, donc les coûts d’hébergement sont importants. C’est pour ça qu’il ne reste plus que de grandes plateformes comme YouTube, tandis que des alternatives comme Nebula, PeerTube ou Odysee ont des limites en matière de qualité ou de coût
  • Avant, l’objectif était d’optimiser pour l’utilisateur ; aujourd’hui, c’est une époque où les entreprises font passer leur propre intérêt avant tout
  • Le standard de diffusion ATSC 3 a lui aussi connu des problèmes de compatibilité avec les anciens récepteurs après l’ajout tardif du DRM

• Depuis 2010, j’utilise yt-dlp, y compris à l’époque de youtube-dl, pour archiver toutes les vidéos que j’aime
  J’en ai maintenant des dizaines de milliers, et une part importante a déjà disparu du site
  Je conserve aussi des vidéos comme les temps forts de sumo de la NHK, qui ne restent disponibles qu’un mois

  • On peut appeler ça une forme de collectionnisme numérique. Ce serait amusant de créer une fonction, à la Google Memories, qui rappelle périodiquement d’anciennes vidéos
  • Beaucoup de chaînes suppriment elles-mêmes leurs vidéos ou les retirent, donc j’ai commencé à les sauvegarder avant que les bons contenus ne disparaissent
  • Sur Internet, tout peut disparaître à tout moment. Ce qui est important, il faut l’enregistrer soi-même pour pouvoir le revoir
  • Je ne pensais pas croiser ici quelqu’un qui archive des vidéos de sumo. On est plus nombreux qu’on ne le croit
  • À l’ère de la surabondance de contenus, je me demande s’il est vraiment nécessaire de tout stocker. Avant, je collectionnais MP3 et films, mais aujourd’hui je ne garde que mes photos dans le cloud

• Au milieu de cette guerre sans fin entre blocage des pubs et insertion de pubs, j’en viens à penser qu’on verra peut-être émerger une AGI/ASI au bout du compte.
  Les deux camps finiront par utiliser des LLM, et les humains se retrouveront au milieu, délestés de leur argent et de leur attention

• Dans 10 ans, YouTube sera peut-être totalement inaccessible depuis un navigateur
  Quand la génération habituée aux applis sur tablette deviendra majoritaire, Google aura peut-être assez confiance pour abandonner le web

  • Pour imposer un vrai DRM, il faut du matériel dédié. Il faudrait que le flux chiffré ne puisse être lu que sur des appareils certifiés niveau L2
  • Les webapps mobiles sont tellement pleines de bugs qu’elles sont presque inutilisables. Même les commentaires disparaissent souvent
  • Malgré tout, Google a toujours conservé une stratégie centrée sur le web
  • Il y a encore beaucoup de gens qui regardent YouTube dans un navigateur, et il existe aussi des alternatives comme bilibili en Chine
  • Mais comme les générations au plus fort pouvoir d’achat utilisent le navigateur, je ne pense pas que Google abandonnera complètement ce marché

• Dans l’issue yt-dlp #14404, il a été proposé d’utiliser Selenium ou un navigateur headless,
  mais l’équipe de maintenance a répondu que « ce serait admettre la défaite et trahir l’esprit du projet »

• Le scraping est vraiment un travail ingrat. Maintenir quelque chose alors que les API cassent sans arrêt et que le fournisseur vous déteste, c’est impressionnant

  • Le fait que « le fournisseur nous déteste » fait presque tout le charme de ce projet
  • Moi, je serais incapable de maintenir yt-dlp. C’est un travail trop usant

• On sent que YouTube adopte une attitude de plus en plus hostile envers les utilisateurs
  blocage des bloqueurs de pub, collecte de contenus pour l’entraînement de l’IA, restrictions de l’API… on dirait qu’ils profitent de l’absence de concurrence

  • En réalité, les vrais clients de Google sont les annonceurs. Nous ne sommes que leur produit
    Ils sont sensibles à la satisfaction des annonceurs, mais traitent les utilisateurs et les créateurs comme des consommables
    Le fait d’avoir commencé en gratuit pour éliminer la concurrence et créer une structure monopolistique relevait d’une forme de stratégie d’appât.
    Il nous faut désormais une nouvelle alternative. Même payante, tant qu’elle est transparente
  • En ce moment, surtout sur les vidéos pour enfants, les publicités impossibles à passer se multiplient
  • Les coûts d’exploitation de YouTube sont tellement élevés que je pense que le blocage des pubs peut affecter le maintien du service
  • Au final, l’UX dégradée (enshittification) elle-même est devenue une composante du modèle économique

• D’après le wiki yt-dlp EJS, Deno est recommandé parce qu’il permet d’exécuter du code avec des permissions limitées et de récupérer à distance les dépendances EJS depuis npm

  • Mais il ne faut pas surestimer le sandboxing de Deno comme mécanisme de sécurité. L’isolation au niveau du runtime reste faible,
    donc il est plus sûr d’utiliser une isolation au niveau OS/VM comme Firecracker
  • Autrefois, yt-dlp interprétait le JS uniquement avec Python, mais avec des exigences de runtime de plus en plus complexes, l’interpréteur maison a fini par atteindre ses limites